Amiga Plus 1995 #2/Amiga Plus CD - 1995 - No. 2.iso/internet/faq/englisch/inn

Text File | 1995-04-11 | 174.3 KB | 4,667 lines

Posted-By: post_faq 2.10
Archive-name: usenet/software/inn-faq/part1
Last Changed: $Id: FAQ-inn.1,v 1.111 1995/03/02 09:14:01 tal Exp $

                  Part 1 of 4

INN FAQ Part 1/4: General Information:
                     Questions from people that don't (yet) run INN
                     Specific notes for specific operating systems
INN FAQ Part 2/4: Debugging Guide & Tutorial:
INN FAQ Part 3/4: Operational and Misc. Questions
INN FAQ Part 4/4: Appendix A: Norman's install guide


------------------------------

Subject:  Table Of Contents for Part 1/4

=====================================================================
        TABLE OF CONTENTS FOR PART 1/4:  General Information
=====================================================================

QUESTIONS FROM PEOPLE THAT DON'T (YET) RUN INN:
    What is INN?
    Where can I get the INN software?
    Where can I get the latest copy of this FAQ?
    What machines does it run on?
    INN must be really complicated since this FAQ is so long!
    Can I run C News with INN?
    Can I run NNTP with INN?
    Can I run the reference implementation (NNTP1.5) with INN?
    Can I run INN on my UUCP-only machine?
    Suppose I have a 286 machine?
    Does INN implement NOV, xthread (trn) or xuser/xmotd (tin) commands?
    Is an ident or authorization protocol supported?
    Does INN do UUCP batching like C News?
    Help!  How do I configure this beast?
    How do I thank the FAQ maintainer?

SPECIFIC NOTES FOR SPECIFIC OPERATING SYSTEMS:
    BASH tips
    GNUS tips
    AIX tips
    SunOS 4.1.2 tips
    Ultrix tips
    HP-UX tips
    UnixWare tips
    Linux tips
    A/UX 3.0 (Macintosh) tips
    Alpha OSF tips
    SGI IRIX 5.x tips
    Pyramid and system's where only root can have "cron" jobs.
    All System V based Unixes (SVR4, Solaris 2.x, SCO ODT 3.0, AIX, A/UX, DELL, ...)
    Solaris 2.x special needs
    Slackware
    3Com Router users
    NOV problems on a Pyramid
    Warnings to people that must set HAVE_UNIX_DOMAIN to DONT


The FAQ was written by Rich $alz <[e-mail]> and is now
maintained by Tom Limoncelli <[e-mail]>.

These documents would not exist if it weren't for the people that have
submitted questions and (most importantly) answers.  THANK YOU ALL!


=====================================================================
           QUESTIONS FROM PEOPLE THAT DON'T (YET) RUN INN
=====================================================================


------------------------------

Subject:  What is INN?

For a complete answer, why not read the Usenix paper that introduced
INN to the world?  It's available as
ftp.uu.net:networking/news/nntp/inn/inn.usenix.ps.Z

InterNetNews is a complete Usenet system.  The cornerstone of the package
is innd, an NNTP server that multiplexes all I/O.  Think of it as an nntpd
merged with the B News inews, or as a C News relaynews that reads multiple
NNTP streams.  Newsreading is handled by a separate server, nnrpd, that is
spawned for each client.  Both innd and nnrpd have some slight variances
from the NNTP protocol (although in normal use you will never notice); see
the manpages.  INN separates hosts that feed you news from those that have
users reading news.  If you need to support a mixed environment you will have
to do some extra work; the installation manual gives some hints.


------------------------------

Subject:  Where can I get the INN software?

The official archive site is ftp.uu.net in the directory
networking/news/nntp/inn.  Archie current lists over 30 archive sites;
three other international sites are ftp.univ-lyon1.fr in
pub/unix/news/inn, munnari.oz.au in pub/news/inn, and src.doc.ic.ac.uk
in computing/usenet/software/transport

The latest version of INN is 1.4sec.  This is rev. 1.4 with a slight
modification of certain shell scripts to fix a security hole.  Do
not run 1.4 without the patch (see part 3/4 of this FAQ).

Patches for INN are at: ftp://ftp.pop.psu.edu/pub/src/news/inn/patches
Add-ons for INN are at: ftp://ftp.pop.psu.edu/pub/src/news/inn/contrib
("Add-ons" include "Gup" and other interesting tools)


------------------------------

Subject:  Where can I get the latest copy of this FAQ?

1.  This four-part FAQ is available via FTP at any FTP site that carries
INN itself.

2.  This FAQ is also posted to news.software.nntp, news.software.b and
    news.answers about every 10 days.

3.  You can also get this FAQ by sending email to
[e-mail] with "get file faq-inn-1" on the first
line of the message.  (the Subject: of the message will be ignored.)
(Substitute faq-inn-2, faq-inn-3 or faq-inn-4 to get those parts).

For example:

echo get file faq-inn-1 | mail [e-mail]
echo get file faq-inn-2 | mail [e-mail]
echo get file faq-inn-3 | mail [e-mail]
echo get file faq-inn-4 | mail [e-mail]

or

% mail [e-mail]
Subject: ignored
get file faq-inn-1
get file faq-inn-2
get file faq-inn-3
get file faq-inn-4
^D

or if you csh and are a total nerd, you can:
    echo 'get file faq-inn-'{1,2,3,4}@ \
        | tr @ '\012' | mail [e-mail]

...or get a real hobby.


------------------------------

Subject:  What machines does it run on?

If you have socket() and select() then INN will probably run on your
machine.  In addition to the common platforms found around the Internet
(SunOS and Ultrix, for example), INN runs on IBM's AIX, Apple's A/UX,
NeXT, Solaris 2.x, most SVR4 platforms, BSDI, most free BSD systems
(NetBSD, FreeBSD, ...) and a host of others.  It might require a
little bit of tweaking of some free BSD platforms that have really bad
shells.

INN has not been ported to Windows NT.  There are no plans to do so.
However, someone has written a package called NNS (Usenet Network News
Server) which is a NNTP-compliant news server for Windows NT.  For
information write to [e-mail].


------------------------------

Subject:  INN must be really complicated since this FAQ is so long!

No, it's just that the FAQ is very complete.  Part 2 is so long because
it includes a tutorial that tries to turn a beginner into an TCP/IP
protocol expert.  Part 3 is long because the FAQ maintainer is
constantly trying to add every question ever asked on
news.software.nntp.  Maybe someone should volunteer to maintain an
index.

A lot of the material could be integrated into the Install.ms doc.

Please post questions to news.software.nntp.  Do not send
email to Tom Limoncelli directly.  By posting your question,
a group of 10 or so people will be trying to help you.


------------------------------

Subject:  Can I run C News with INN?

No.  INN handles all article reception, filing, forwarding, and
expiration.  You will get a corrupted database if you try to
run INN with any other news system.  For testing, you can probably shut
down your old system, bring up INN, and then reverse the process.  (INN
uses the C News history file and DBZ database, so if you don't run C News
you will have to do some fiddling around with those files.)


------------------------------

Subject:  Can I run NNTP with INN?

There's a confusion here.  NNTP is a protocol, defined in RFC 977.  There
is also an implementation of the protocol, NNTP1.5, that many people call
NNTP.  When there was only one implementation of the protocol, that was
okay, but now that there are other implementations (for example, INN) it
is getting confusing.  It would be as if "sendmail" were named "smtp."
Please try to be clear -- do you mean the NNTP protocol, or the NNTP
reference implementation currently maintained by Stan Barber?


------------------------------

Subject:  Can I run the reference implementation (NNTP1.5) with INN?

The quick answer is no.  INN listens on the NNTP port and handles all
incoming traffic.  It receives articles, files them, and arranges for
them to be forwarded to your peers.  If a site connects that is not
listed as a peer (e.g., a local workstation that does newsreading) then
the INN server hands the connection off to another program that handles
just the NNTP commands that newsreaders use.  By default, this is nnrpd
(notice the "r"), which implements the NNTP protocol for newsreaders
(for example, it includes the POST command but not the IHAVE command).
You can run the reference implementation server instead of nnrpd if you
want.  Doing this can be useful if you have clients that want to do
both reading and article transfer.


------------------------------

Subject:  Can I run INN on my UUCP-only machine?

Sure.  While not designed for this, several people are running INN on
machines that do not have IP-connectivity (such as UUCP-only hosts) and
are quite happy with it.  You might want to give it a try, especially if
you think you will be joining the Internet some day.


------------------------------

Subject:  Suppose I have a 286 machine?

Won't work.  INN is designed to be a memory hog; a server that has been up
for a few days while will have a working set size of a few to several
megabytes, although not all of it will be resident.  For example, the
server keeps the active file and list of who gets what in memory, as well
as all articles that it is receiving.  Unless you can do things like
"malloc(64 * 1024)" without pain, INN won't work on your machine.


------------------------------

Subject:  Does INN implement NOV, xthread (trn) or xuser/xmotd (tin) commands?

Newsreaders all need some way to quickly grab data from
a range of articles.  trn, tin, nn, and others each developed
their own database format, and their own extensions to the NNTP
protocol for clients to read the database.  Then, Geoff Collyer
invented NOV, the database to end all other databases.

Rather than support a different database format for each newsreader,
INN supports Geoff Collyer's news overview database, NOV.  INN includes
everything you need to create/maintain/expire NOV's .overview files.
You only need Geoff's distribution (available via FTP on world.std.com
src/news/nov.dist.tar.Z) if you want to see how he implements things,
or to get his client library (useful when building some newsreaders).

It is very easy to configure INN to use NOV.  Read Part 2/4 of
this faq: Subject: Cookbook example of setting up NOV ("overchan")
NB: The NOV code in INN 1.3 is buggy.  Use 1.4 or higher.

The xover command is used for querying the NOV database.  The xover
command is very smart in that if the article has been canceled, the
data isn't given out.  If the article is so new that it's data isn't in
the NOV database, nnrpd opens the article and digs out the data.  xhrd
and xpat make every effort to use NOV data before they dig the data out
of the actual articles, thus making them considerably faster than other
implementations.  The "xoverview" command does not exist.  If your
server supports this command you need to upgrade.

What about TRN's xthread command?

The xthread command has code but it is not supported; look at
$inn/nnrpd/nnrpd.h.  This code will probably vanish after 1.4.

What about TIN's many commands?

Tin commands are not supported.  However, other people have
added TIN support.  See the next section.



------------------------------

Subject:  Is an ident or authorization protocol supported?

An unsupported patch for nnrpd to add ident support can be found via
FTP at ftp.csie.nctu.edu.tw:/pub/news/nnrpd-identd-patch.shar.gz.  It
includes patches to add tin's xuser and xmotd commands as well as a
list subscription system. ([e-mail])

Remember: ident information is only as valid as the server you connect
to.  Any fool with root access (or anyone with a PC or Mac) can create
a bogus ident server that will give out whatever information they want
you to see.  It's not an authorization or identification protocol, it's
just informational.

The authd protocol is added to nnrpd by <[e-mail]>.
This unsupported patch can be found in
ftp.geophys.hokudai.ac.jp:/pub/network/news/inn/patches/authd-patch-1.3.tar.gz
The documentation is in Japanese.  Good luck.

In a future release, you will be able to log all POST commands with
ident information if you so choose.  (Maybe INN 1.5)


------------------------------

Subject:  Does INN do UUCP batching like C News?

Not as part of the standard distribution.  The batching system right
now is better than B News, but Rich has said he will be working on
improving that part of INN in a future release.  Christophe Wolfhugel
<[e-mail]> has written a package that is
very much like the C News batching system, however.  You can find it on
ftp.univ-lyon1.fr in the pub/unix/news/inn/contrib directory.

Version 3 of Christophe's package includes a shell version and a Perl
version.  Version 4, not yet planned will only be in Perl.  The
configuration file has evolved from older releases in order to support
new features like "minimum batching".


------------------------------

Subject:  Help!  How do I configure this beast?

READ AND FOLLOW THE "Install.ms" FILE.  This FAQ is meant to add to
what Install.ms says not replace it.

Many people that thought the Install.ms doc was incomplete later
re-read the "First Time Installation" portion and were amazed how much
they missed (or just plain skipped) the first time.

You should also purchase the O'Reilly And Associates book on Managing
Usenet to give yourself a good grounding on how to run a site.


------------------------------

Subject:  How do I thank the FAQ maintainer?

If you find this document useful, please consider making a donation to
the maintainer's favorite charity:

    The Personal Liberty Fund
    PO Box 11335
    New Brunswick, NJ 08906-1335
    USA

The PLF is a legal and educational organization which helps people in
New Jersey, USA.  They have many on-going projects which range from
combating youth suicide to legal advocacy.  Their Anti-Violence Project
runs a phone hotline for reporting gay-bashing which helps hundreds of
people a year.  The PLF is an all-volunteer organization and couldn't
survive without donations.  The PLF is recognized by the IRS as a
501(c)3 tax-exempt charity.  Donations are tax deductible to the
fullest extent of the law (U.S. citizens only).  Please write "INN" in
the memo field of the check.  Fifteen, fifty, or five hundred dollars...
every penny is appreciated!


======================================================================
            SPECIFIC NOTES FOR SPECIFIC OPERATING SYSTEMS
======================================================================

------------------------------

Subject: BASH tips

If you are using a Unix who's /bin/sh is a hardlink to
bash, you'll find problems using nntpsend.  nntpsend uses
a variable named PPID, which is a read-only variable in BASH.

You'll get errors that look like this:
sh: PPID: read-only variable

You can fix it using the the following patch:


*** nntpsend~   Thu Aug 12 03:36:16 1993
--- nntpsend    Sat Oct 23 15:54:11 1993
***************
*** 1,4 ****
! #! /bin/sh
  ##  $Revision: 1.111 $
  ##  Send news via NNTP by running several innxmit processes in the background.
  ##  Usage:
--- 1,4 ----
! #!/usr/local/bin/bash
  ##  $Revision: 1.111 $
  ##  Send news via NNTP by running several innxmit processes in the background.
  ##  Usage:
***************
*** 130,140 ****
      chmod 0660 ${LOG}
      exec >>${LOG} 2>&1
  fi
! PPID=$$
! echo "${PROGNAME}: [${PPID}] start"

  ##  Set up environment.
! export BATCH PROGNAME PPID INNFLAGS

  ##  Loop over all sites.
  cat ${INPUT} | while read SITE HOST MAXSIZE FLAGS; do
--- 130,140 ----
      chmod 0660 ${LOG}
      exec >>${LOG} 2>&1
  fi
! CPID=$$
! echo "${PROGNAME}: [${CPID}] start"

  ##  Set up environment.
! export BATCH PROGNAME CPID INNFLAGS

  ##  Loop over all sites.
  cat ${INPUT} | while read SITE HOST MAXSIZE FLAGS; do
***************
*** 240,246 ****
      fi

      ##  Start sending this site in the background.
!     export SITE HOST LOCKS BATCHFILE PROGNAME PPID SIZE TMPDIR
      sh -c '
        BATCHFILE=${HOST}.nntp
        LOCK=${LOCKS}/LOCK.${HOST}
--- 240,246 ----
      fi

      ##  Start sending this site in the background.
!     export SITE HOST LOCKS BATCHFILE PROGNAME CPID SIZE TMPDIR
      sh -c '
        BATCHFILE=${HOST}.nntp
        LOCK=${LOCKS}/LOCK.${HOST}
***************
*** 247,253 ****
        trap "rm -f ${LOCK} ; exit 1" 1 2 3 15
        shlock -p $$ -f ${LOCK} || {
            WHY="`cat ${LOCK}`"
!           echo "${PROGNAME}: [${PPID}:$$] ${HOST} locked ${WHY} `date`"
            exit
        }
        if [ -f ${SITE}.work ] ; then
--- 247,253 ----
        trap "rm -f ${LOCK} ; exit 1" 1 2 3 15
        shlock -p $$ -f ${LOCK} || {
            WHY="`cat ${LOCK}`"
!           echo "${PROGNAME}: [${CPID}:$$] ${HOST} locked ${WHY} `date`"
            exit
        }
        if [ -f ${SITE}.work ] ; then
***************
*** 254,259 ****
--- 254,260 ----
            cat ${SITE}.work >>${BATCHFILE}
            rm -f ${SITE}.work
        fi
+       if [ -s ${SITE} ] ; then
        mv ${SITE} ${SITE}.work
        if ctlinnd -s -t30 flush ${SITE} ; then
            cat ${SITE}.work >>${BATCHFILE}
***************
*** 260,273 ****
            rm -f ${SITE}.work
            test -n "${SIZE}" && shrinkfile -s${SIZE} -v ${BATCHFILE}
            if [ -s ${BATCHFILE} ] ; then
!               echo "${PROGNAME}: [${PPID}:$$] begin ${HOST} `date`"
!               echo "${PROGNAME}: [${PPID}:$$] innxmit ${INNFLAGS} ${HOST} ..."
                eval innxmit ${INNFLAGS} ${HOST} ${BATCH}/${BATCHFILE}
!               echo "${PROGNAME}: [${PPID}:$$] end ${HOST} `date`"
            else
                rm -f ${BATCHFILE}
            fi
        fi
        rm -f ${LOCK}
      ' &
      sleep 5
--- 261,275 ----
            rm -f ${SITE}.work
            test -n "${SIZE}" && shrinkfile -s${SIZE} -v ${BATCHFILE}
            if [ -s ${BATCHFILE} ] ; then
!               echo "${PROGNAME}: [${CPID}:$$] begin ${HOST} `date`"
!               echo "${PROGNAME}: [${CPID}:$$] innxmit ${INNFLAGS} ${HOST} ..."
                eval innxmit ${INNFLAGS} ${HOST} ${BATCH}/${BATCHFILE}
!               echo "${PROGNAME}: [${CPID}:$$] end ${HOST} `date`"
            else
                rm -f ${BATCHFILE}
            fi
        fi
+       fi
        rm -f ${LOCK}
      ' &
      sleep 5
***************
*** 275,278 ****

  wait
  rm -f ${INPUT}
! echo "${PROGNAME}: [${PPID}] stop"
--- 277,280 ----

  wait
  rm -f ${INPUT}
! echo "${PROGNAME}: [${CPID}] stop"


------------------------------

Subject:  GNUS tips

In article <3g82ll$[e-mail]> [e-mail] (Emilio Losantos) writes:

> I have to use GNUS 4.1 to read news from a nntp server running INN 1.4, but
> whenever I try to select a group I receive the message:

>  "GROUP" not implemented; try "help"

> Could anybody tell me how to fix this problem?

[e-mail] (Jack Bryans) replies:

Patch your nntp.el something like this:

*** 72,77 ****
--- 72,79 ----
    (set-process-sentinel nntp/connection 'nntp/sentinel)
    (process-kill-without-query nntp/connection)
    (let ( (code (nntp/response)) )
+     (nntp/command "mode reader")
+     (nntp/response)
      (or (eq code 200) (eq code 201))))

  (defun nntp-server-opened ()

Note that your line numbers may vary.  There's a lot of nntp.el's out there.



------------------------------

Subject:  AIX tips

Q:  In config.data, should ACT_STYLE be set to READ or MMAP?

A:  Gee, some say MMAP works, some say it doesn't.  I recommend you use
READ.  After you've been running for a month, try MMAP for a day and
see what happens.


Q: What compiler should I use?

A: Most people use what's listed in Install.ms, though we have
one report of a AIX 3.2.5 user that found bsdcc worked better.


Q: When I run news.daily, there's always a few lines of error
messages at the end of the output:

    compress: bad file number

A:  AIX /usr/bin/compress has a bug when compressing files with zero
length. Then it spits out this error.  Solution: Ignore it or use a
different compress programm and change config.data accordingly.
(from Kurt Jaeger <[e-mail]>)


Q:  innwatch doesn't work well from /etc/inittab, does it?

A:  Nope.  Instead, you can create a "subsystem" with this command:

mkssys -s innwatch -p /usr/local/news/bin/innwatch \
    -u `id -u news` -G news -S -n 15 -f 9

Note that your path to innwatch may differ, depending on where you
decided to install the inn components.  You also need to enter the
command as one long line.

This will create a subsystem named "innwatch" belonging to an SRC group
named "news".  The "-S" means that it uses signals for SRC to tell it
when to stop and the "-n" is the SIGTERM signal, for normal shutdown,
and the "-f" is the SIGKILL signal, which is sent if the process does
not stop within 20 seconds.  Then, modify rc.news to issue the command

    startsrc -s innwatch

to get innwatch going.  That's it!

Shane Castle <[e-mail], [e-mail]>


Q:  When I compile I get something like:
    0706-317 ERROR: Unresolved or undefined symbols detected:
        Symbols in error (followed by references) are
        dumped to the load map.
        The -bloadmap:<filename> option will create a load map.
        .dbzwrit
    cd frontends ; make  all ; cd ..
    Target all is up to date.
A:  That means you don't have a program called "patch" installed on
your machine.  Refer to "Subject:  ld.so: Undefined symbol: _dbzwritethrough"


Q:  What can I change in innwatch.ctl to make it work right?

A:  The "df" command in AIX has a funny output that requires you to
modify innwatch.ctl.  The FTP site has an install.ctl that uses "df -i"
(some AIX versions) and another one that uses "df -v" (recommended by
someone with AIX 3.2.5).


------------------------------

Subject:  SunOS 4.1.1 tips

SunOS 4.1.1 (but not 4.1.2 or 4.1.3) broke the write system call but a
patch is available.  Any write could fail "half way", it is just more
likely to happen when writing large files and in-core DBZ writes the
history file out in one chunk.  The "Known Problems" section of the
installation manual says to install Patch 100293-01, but that has
been replaced by 100622-01.


------------------------------

Subject:  Ultrix tips

Tip #1:  Ultrix has a "mmap()" function, but it doesn't do the same
thing as the SunOS/BSD mmap() function.  Therefore, do not configure
INN to use mmap() on a Ultrix system.  INN wants to find a mmap()
function that is like the one on SunOS/BSD systems.

Tip #2:  The sendsys script breaks Ultrix 'nawk'.  You can make
a 1-line change or you can switch to 'awk' or "gawk".
Original line:
    ${AWK} "/^$1"'[/:\\]/,/[^\\]$/' ${NEWSFEEDS} >${TEMP}
Modified line:
    ${AWK} "/^$1"'[\/:\\]/,/[^\\]$/' ${NEWSFEEDS} >${TEMP}
The original line will work with awk, gawk, but not nawk.
The modified line will work with awk, gawk, or nawk.
If you have gawk running on your machine use it.  Otherwise, switch to
awk.

Tip #3: The syslog on Ultrix sucks rotten eggs and Digital refuses to
fix it.  (source: everyone that uses Ultrix and has ever used other
systems)  Luckily, you can replace it with the routine that comes with
INN.  However, some people have had better luck installing the syslog
that can be found on
"gatekeeper.dec.com:/pub/DEC/jtkohl-syslog-complete.tar.Z".  It still
works with old clients but does new-style syslogging, too.  Works great
for me so far.  (this information from:  [e-mail] (Nelson
Minar)).  The syslog that is shipped with INN works pretty well but
there have been some claims that some old clients don't like it.


------------------------------

Subject:  HP-UX tips

Q.  My logs keep telling me there is no space for articles
A.  Edit innwatch.ctl to use "bdf" instead of "df".

Q. I am running inn on an HP machine. INN won't start up automatically.
I can start it manually.  There is no problem with news or INN once
it is started.

A.  Try adding a "sleep 10" to the bottom of /etc/rc.news, or in
/etc/rc, right after /etc/rc.news is invoked.  On some machines,
including HP, the shell started by "#!/bin/sh" when /etc/rc is executed
will exit before innd has disassociated itself from that shell.  This
causes innd to exit, sometimes without printing an error message.
(source: [e-mail] (Paul Joslin ))

This problem goes away if you set HAVE_SETSID to "DO".  Something to do
with Posix Session Leader concepts.  Ick.  (source: Steve Howie
<[e-mail]>).  You can also do something like:

    echo /usr/lib/etc/rc.news | at now + 2 minutes

HP-UX 8.x and 9.x users might find a problem with getting innwatch to
start up.  People have found that having "at" start it seems to work
more reliably than other methods:

${DOINNWATCH} && {
    echo "${INNWATCH} &" | su ${NEWSUSER} -c 'at now + 2 min' > /dev/null
}

The '&' in the command line prevents innwatch from taking up an at-job
slot.  SysV-style crons have a per-category and overall limit on the
number of jobs executing simultaneously.

Q:  INN-1.4sec running on an HP9000 s700 with HP-UX 9.01 leaks memory
like crazy.  The innd process grows and grows, then stops with:

    "ME cant remalloc 8192 bytes Not enough space"

A:  The cause turns out to be a memory leak in the standard C library (both
/lib/libc.a and /lib/libc.sl).  Installed patch PHCO_5056 (or the latest
libc patch).


------------------------------

Subject:  UnixWare tips

UnixWare 1.1.2 works with domain sockets.  Install
ptf149 "unix domain sockets" and
ptf678 "fix for sockmod's incorrect handling of disconnect indication"

Otherwise, configure like any SVR4 system.


------------------------------

Subject:  Linux tips

Get inn-1.4-linux-0.1.tar from ftp myriad.pc.cc.cmu.edu /pub/linux It
contains instructions for installing INN on a Linux system and a
working config.data file.  (from [e-mail])

If you are too stupid to follow the directions in
inn-1.4-linux-0.1.tar, here are some of the problems you might have:

| nntpsend.log says the following.

| nntpsend: [214:222] innxmit -a -t300 -T1800
| travelers.mail.cornell.edu ...
| Ignoring line "cornell/test/13 805 ..."
| sh: PPID read-only variable

Tomasz Surmacz <[e-mail]> writes:

If you are using INN under Linux or have your /bin/sh a symlink to
/bin/bash the above problem appears (in nntpsend precisely speaking,
not innxmit)

The problem is that bash already defines the PPID variable and
nntpsend is trying to use it too.  To fix this:

1. comment out line PPID = $$
2. change all occurences of PPID to say PARENTPID

I have also noticed that changing first line of nntpsend from
'#!/bin/sh' to "!/bin/bash" helps in such occasions.


------------------------------

Subject:  A/UX 3.0 (Macintosh) tips

Tip #1: Use the INN malloc.

Tip #2:  If you are running INN 1.4 on a Mac running A/UX 3.0.1, Every
so often, (generally when someone fires up a reader), INN goes beserk.
Syslog says:

    innd: ME cant select Bad file number

This message repeats about 20 times per second.  It freezes up my
computer and I need to reboot.

That's a kernel bug. You do have to reboot.

If you compiled inn with gcc, don't. My experience was that somehow, if
INN was compiled with GCC the kernel bug is triggered, but that doesn't
happen with cc.


------------------------------

Subject:  Alpha OSF tips:

To compile INN for the DEC Alpha, follow the instructions in the INN
patch archive on ftp.pop.psu.edu:/pub/src/news/inn-patches

A config.data file for OSF1.3a is in:
    ftp://pirates.cs.swt.edu/pub/usenet/inn/inn1.4/config
A config.data file for OSF3.0 is in:
    ftp://pirates.cs.swt.edu/pub/usenet/inn/inn1.4sec/config

In rc.news you need to start $INNWATCH using the following:

${DOINNWATCH} && {
    echo "${INNWATCH} &" | su ${NEWSUSER} -c 'at now + 2 min' > /dev/null
}

The '&' in the command line prevents innwatch from taking up an at-job
slot.  SysV-style crons have a per-category and overall limit on the
number of jobs executing simultaneously.


------------------------------

Subject:  SGI IRIX 5.x tips

Some people have reported that IRIX 5.1 isn't very reliable and that it
is worth it to run 5.2.   5.3 is even better, but it is still not
perfect.  (In other words: IT WORKS FINE AS Install.ms DESCRIBES!)


------------------------------

Subject:  Pyramid and system's where only root can have "cron" jobs.

Your cron jobs may not work if you use:

    su news -c /usr/lib/news/bin/news.daily delayrm expireover

Instead, you must put the entire command in quotes.  Like this:

    su news -c "/usr/lib/news/bin/news.daily delayrm expireover"

Look for "Pyramid" later in this FAQ for the interesting details.

------------------------------

Subject:  System V based Unixes (SVR4, Solaris 2.x, SCO ODT 3.0, AIX, A/UX, DELL, ...)

NOTE:  Solaris 2.x is based on SVR4.0.  These tips are useful in a
limited way.  Read this section for general advice, but follow the
"Solaris 2.x" section details.

If you are running any non-BSD (i.e. System V based) Unix you MUST have
the following option set:

##  How should close-on-exec be done?  Pick IOCTL or FCNTL.
#### =()<CLX_STYLE              @<CLX_STYLE>@>()=
CLX_STYLE               FCNTL

This includes SVR4, Solaris 2.x, A/UX and SCO ODT 3.0.  (SVR4 means
systems based on System V Release 4 from USL.  Please check your manual
to see if your operating system is based on SVR4.)

This CLX_STYLE setting is clearly stated in the Install.ms file and
repeated here since so many people post to news.software.nntp after
ignoring the warnings.

If CLX_STYLE isn't set to FCNTL, you'll get tons of overchan processes
hanging around.

With SCO ODT 3.0 and MOST systems, innd will link and run if you use
IOCTL but eventually will stop answering incoming calls.

Don't be fooled.  Just because it compiles doesn't mean it's going to
work.

If you start innd on an AT&T SysV Rel 4.0 machine and get syslog
messages like:
    localhost:15 cant setsockopt(SNDBUF) Protocol error
    localhost:15 cant setsockopt(RCVBUF) Protocol error
then you should FIRST try to change HAVE_UNIX_DOMAIN to "DONT" in
config.data.  If that doesn't fix the problem, you should add
"-USO_SNDBUF" to your DEFS parameter in config.data.  Or, you can
comment out the "setsockopt()" calls.  This is also mentioned
in the Install.ms file (which means if you needed to read it
here, you weren't paying attention when you read Install.ms)

Many SVR4 for i486 binaries (sendmail, mh, vmail, innd, rnews are now
on ftp.germany.eu.net in pub/comp/i486/svr4/*.SVR4.tgz But remember
that some of the above need site specific changes, so their usefulness
may be limited.

If you get syslog messages that say, "ME cant accept RCreader"
please refer to Part 2 of this FAQ.

DELL ships their Unix with /dev/log chmod'ed to 0644 which means nobody
can syslog anything.  Pretty stupid, eh?  INN uses syslog extensively.
If you find that you don't get any syslog messages check to see if you
need to: "chmod 0666 /dev/log".

Nobody knows by SVR4 boxes often give error messages like,
"innd:  accept: SIOCGPGRP failed errno 22".  There's some sort of
obscure bug with the SVR4 accept() call that can lead to these
messages, if the executable is linked a certain way. I suspect that the
same symbol -- for two totally separate variables or routines -- is
defined in two different libraries, so if you link in certain ways you
get the "wrong" thing. This error drove me crazy when I first built
sendmail V8 on our NCR 3000 box. But I re-linked it a different way and
I haven't seen the error since. Good riddance. I suggest you play
around with your link libraries and/or order of linkage.

[e-mail] (Kevin Darcy) says he never gets theses messages since
he started using (in config.data):
LIBS                    -lsocket -lnsl -lelf


If your SVR4 system still doesn't run correctly, check the
Solaris 2.x suggestions.


------------------------------

Subject:  Solaris 2.x special needs

SOLARIS 2.4:  Install the Recommended cluster patch from Sun.
The Recommended cluster patch is:
ftp://sunsolve1.sun.com/pub/patches/2.4_Recommended.tar.Z
The README is:
ftp://sunsolve1.sun.com/pub/2.4_Recommended.README
Then follow the directions in
ftp://ftp.pop.psu.edu/pub/src/news/inn/patches/solaris-2.4.patch.
The patch needs to be applied BY HAND, it is not in the correct format
to work with Larry Wall's patch program.  Also, do *not* link with the
/usr/ucblib stuff, and HAVE_WAITPID should be set to "DO".

SOLARIS 2.3:  If you install the "Recommended cluster patch" I *think*
you will only need to pay attention to Fix #5 listed below.  It would
be helpful if people sent an update about this.
The Recommended cluster patch is:
ftp://sunsolve1.sun.com/pub/patches/2.3_Recommended.tar.Z
The README is:
ftp://sunsolve1.sun.com/pub/2.3_Recommended.README

(note: If you trust other people to compile programs for you
[especially ones that run as root] you can get inn1.4sec pre-compiled
w/gcc at ccnews.ke.sanet.sk:/pub/solaris/inn1.4sec-src+bin.tar.gz)

INN works with Solaris 2.[0123].  It's not easy, but it will work.
The problem is that depending on which Solaris patches you have
installed, you have to install various INN patches.  There are too
many combinations of Sun patches and INN patches to be able to say
what is required and what isn't.  (See the "SOLARIS 2.3" tip above
for one tried and tested configuration).

Here is the general guide:

Step 1:  Use the info for config.data for Solaris 2.x that is included
    Install.ms.
Step 2:  As you go, if you get any of the problems listed below, try
    the fix listed.

Eventually you will be up and running with only the fixes you need.  If
you try to install ALL the fixes at once, things will definately not
work.

COMPILER TIPS:  Use gcc or /opt/SUNWspro/bin/cc.  Do *not* use
/usr/ucb/cc.  In fact, remove /usr/ucb from your path when you compile.


---------- Solaris Fix #1

Under Solaris 2.[012] (SunOS 5.0, 5.1, 5.2) you must add the following
at the beginning of each file using gethostbyname():

#define gethostbyname __switch_gethostbyname

Under Solaris 2.3 gethostbyname() might work without changes depending
on your configuration.  We haven't figured out when they work and when
they don't.  If you run into problems, try to change "gethostbyname()"
to "solaris_gethostbyname()" and then use the gethostbyname() listed in
the Solaris Porting FAQ.  This isn't a perfect solution, because you
now need a different binary for Solaris 2.[012] systems.

It would be great if someone were to submit a solaris_gethostbyname()
function who's binary works under all Solaris revs and gives all the
semantics of BSD gethostbyname().  In particular, one that doesn't have
the problems discussed in sun bugid #1126573 or #1135988.  It would be
amazing if this was submitted by one of the many Sun employees that
flame the INN FAQ maintainer in comp.sys.sun.admin everytime he bitches
about how much he hates Solaris 2.x. :-)

---------- Solaris Fix #2

Under all Solaris 2.* versions there is a problem with innwatch.ctl.
It expects to use "df -i" to find out how many inodes are free on your
disk.  /usr/{sbin,5bin,bin}/df doesn't support the "-i" option, it has
a "-e" option that outputs the info you want, but in a different
format.  You should use "/usr/ucb/df -i" instead, since this version of
df includes the "-i" option.

/usr/ucb/df is part of the BSD Compatibility stuff.  If you loaded
Solaris 2.x without that, you can replace innwatch.ctl's disk checks
with these lines:

##  If load is OK, check space (and inodes) on various filesystems
##  =()<!!! /usr/bin/df -k . | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_SPOOLSPACE>@ ! throttle ! No space (spool)>()=
!!! /usr/bin/df -k . | awk 'NR == 2 { print $4 }' ! lt ! 8000 ! throttle ! No space (spool)
##  =()<!!! /usr/bin/df -k @<_PATH_BATCHDIR>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_BATCHSPACE>@ ! throttle ! No space (newsq)>()=
!!! /usr/bin/df -k /news2/spool/out.going | awk 'NR == 2 { print $4 }' ! lt ! 800 ! throttle ! No space (newsq)
##  =()<!!! /usr/bin/df -k @<_PATH_NEWSLIB>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_LIBSPACE>@ ! throttle ! No space (newslib)>()=
!!! /usr/bin/df -k /news2/privcontrol | awk 'NR == 2 { print $4 }' ! lt ! 40000 ! throttle ! No space (newslib)
##  =()<!!! /usr/bin/df -k @<_PATH_OVERVIEWDIR>@ | awk 'NR == 2 { print $4 }' ! lt ! @<INNWATCH_OVERVIEWSPACE>@ ! throttle ! No space (overview)>()=
!!! /usr/bin/df -k /news3/overview | awk 'NR == 2 { print $4 }' ! lt ! 6000 ! throttle ! No space (overview)
##  =()<!!! /usr/bin/df -e . | awk 'NR == 2 { print $2 }' ! lt ! @<INNWATCH_SPOOLNODES>@ ! throttle ! No space (spool inodes)>()=
!!! /usr/bin/df -e . | awk 'NR == 2 { print $2 }' ! lt ! 200 ! throttle ! No space (spool inodes)

---------- Solaris fix #3

Don't run the "lint" step if you use Solaris.  In fact, nobody needs to
execute this step except Rich, when he's writing new code.  If you have
a Solaris machine without "lint", just make "lint" a symlink to
"/bin/echo".

---------- Solaris fix #4

People running Solaris 2.3 have built INN with HAVE_UNIX_DOMAIN set to
TRUE and everything seems to be ok.  I guess Sun has fixed enough
bugs in 2.3 to make it usable.  I recommend the latest "recommended
patches" if you run any version of Solaris 2.x.  To install all of
the "Recommended Patches" in one command, refer to:
ftp://sunsolve1.sun.com/pub/patches/patches.html

---------- Solaris fix #5

If "inews" outputs "Bad Message-ID" when posting Under Solaris 2.x
(where x = 0, 1, 2 or 3) you need to change the file "getfqdn.c".  Find
the lines that read:

    if (strchr(hp->h_name, '.') == NULL) {
        /* Try to force DNS lookup if NIS/whatever gets in the way. */
        (void)strncpy(temp, buff, sizeof buff);
        (void)strcat(temp, ".");
        hp = gethostbyname(temp);
    }

and delete them.

---------- Solaris fix #6

If posting gets you "441 Can't generate Message-ID, Error 0" and you
are running with DNS, then the problem is with Solaris 2.3's
gethostbyname.  dns.  If you ask for a host with "hostname." it returns
"hostname." instead "hostname.yourdomain.com" as expected by nn.  The
workaround is to define "domain" in your inn.conf and apply the
following patch to getfqdn.c:

*** getfqdn.c.~1~       Sun Sep  4 09:02:37 1994
--- getfqdn.c   Sun Sep  4 09:53:11 1994
***************
*** 35,45 ****
      if ((hp = gethostbyname(buff)) == NULL)
        return NULL;
!     if (strchr(hp->h_name, '.') == NULL) {
!       /* Try to force DNS lookup if NIS/whatever gets in the way. */
!       (void)strncpy(temp, buff, sizeof buff);
!       (void)strcat(temp, ".");
!       hp = gethostbyname(temp);
!     }
!     if (hp != NULL && strchr(hp->h_name, '.') != NULL) {
        if (strlen(hp->h_name) < sizeof buff - 1)
            return strcpy(buff, hp->h_name);
--- 35,39 ----
      if ((hp = gethostbyname(buff)) == NULL)
        return NULL;
!     if (strchr(hp->h_name, '.') != NULL) {
        if (strlen(hp->h_name) < sizeof buff - 1)
            return strcpy(buff, hp->h_name);


------------------------------

Subject:  Slackware Tips

Slackware comes with The Reference Implementation of NNTP as well as
INN.  However, if you select "INN" it doesn't remove the nntp entry in
your /etc/inetd.conf.  If the Slackware people aren't sure why INN
requires you to remove that line from /etc/inetd.conf, they should get
out of the business.  (oh, they can complain to [e-mail]... he wrote
this paragraph).


------------------------------

Subject:  3Com Router users

If you observe strange behavior, like nnrpd locking and not sending
some articles to the clients, and if you find no clues about other
potential problems, then check your IP layer: some users have observed
bugs in the IP implementation of 3Com routers caused TCP
sessions lock outs.  You have very probably also NFS problems then.
Upgrading to the latest PROMs fixes this totally bizarre problem.


------------------------------

Subject:  NOV problems on a Pyramid

Q:  I just turned on the overview stuff and I don't think news.daily is
properly expiring the .overview files.  I'm using a Pyramid.

A:  Do you need quotes in your crontab entry?  Look at your news.daily
report -- expire using "expireover delayrm" should take a few minutes.
If it takes longer than, say, 10-20 minutes, then the keywords aren't
being seen by news.daily so perhaps the commandline quoting is wrong.

i.e. you had:

    su news -c /usr/lib/news/bin/news.daily delayrm expireover

You should have:

    su news -c "/usr/lib/news/bin/news.daily delayrm expireover"

Without quoting, the options are thrown away and only the "news.daily"
is executed.

------------------------------

Subject:  Warnings to people that must set HAVE_UNIX_DOMAIN to DONT

Disclaimer:  First of all, if you have to set HAVE_UNIX_DOMAIN to DONT,
YOU HAVE TO SET IT to DONT.  It's not a choice you can make, it's a
description of the operating system that you've purchased.  If you've
wrongly set this variable to DO your system isn't going to work *at*
*all*.

When you use POST (the NNTP command), you are talking to nnrpd.  nnrpd
cleans up your headers, adds the missing headers that it is allowed to
add, checks whatever it checks, and then submits the finalized version
to innd.  How does it talk to innd?

If you have HAVE_UNIX_DOMAIN set to DO, nnrpd opens a Unix domain
socket and sends the text.  At this point it is talking to innd
somewhat like ctlinnd does.  innd can trust that the post isn't
forged since it is coming from a program trustworthy enough to
get to the socket (which isn't much).

If you have HAVE_UNIX_DOMAIN set to DONT, it has no choice but to open
a socket to port 119, issue the "IHAVE" command, and send the text that
way (just like a remote newsreader).  This means that innd (not another
nnrpd) has to be at the other end of the pipe.  If it opens the
connection and sees a "nnrpd" you're hosed and you get "441 480
Transfer permission denied".  (Better the "441 480" message than an
infinate loop of nnrpd's connecting to nnrpd's!)  To get innd to not
hand off the connection to a nnrpd process, you must have the host's
name in the hosts.nntp file.  (don't forget to do "ctlinnd reload
hosts.nntp")

If you have your host's name in the hosts.nntp file, then any
newsreader running on your nntphost must be "INN-aware" (i.e. that they
issue the "mode reader" command) or they must read news via the file
system instead of NNTP.

If you have NNTP-based newsreaders that can't send the "mode reader"
command, you can try including "server: localhost" in your inn.conf
file, but then you must have a different inn.conf file for the other
machines.  If you can't do that, you have no other options but to
recompile your newsreaders.

Remember, if you change your inn.conf file, you must shutdown and
restart innd.  There is no "ctlinnd reload inn.conf" command.

--
 George Will, Rush Limbaugh, John Sununu, Pat Buchanan, James Kilpatrick, Mona
  Charen, G. Gordon Liddy, Robert Novak, Bay Buchanan, Pat Robertson, Joseph
   Sobran, Paul Harvey, Phyllis Schafly, Maureen Reagan, and John McLaughlin
          always bemoan the need for more conservative media voices.
Posted-By: post_faq 2.10
Archive-name: usenet/software/inn-faq/part2
Last Changed: $Id: FAQ-inn.2,v 1.70 1995/02/26 09:14:01 tal Exp $

                  Part 2 of 4

INN FAQ Part 1/4: General Information
INN FAQ Part 2/4: Debugging Guide & Tutorial
                     Reasons why INN isn't starting
                     The debugging tutorial
                     Other error messages and what they mean
INN FAQ Part 3/4: Operational and Misc. Questions
INN FAQ Part 4/4: Appendix A: Norman's install guide


------------------------------

Subject:  Table Of Contents for Part 2/4

=====================================================================
     TABLE OF CONTENTS FOR PART 2/4:  Debugging Guide & Tutorial
=====================================================================

REASONS WHY INN ISN'T STARTING:
    What runs as what?
    Why does innd just exit right away with no message?
    syslog message: ME internal no to group
    syslog message: ME internal no control and/or junk group
    syslog message: Can't setup communication (bind failure)
    syslog message: ME bad_newsfeeds no feeding sites
    syslog message: ME cant GetConfigValue
    syslog message: ME cant accept RCreader
    syslog message: ME cant ioctl(TIOCNOTTY) Invalid argument
THE DEBUGGING TUTORIAL:
    Should I read the Install.ms file in its entirety
        before reading this document?
    Terminology used in the rest of this document.
    How does it all fit together?
    What should I monitor as I debug INN problems?
    My innd won't start!
    Connecting to a TCP/IP server.
    Make sure that "feeders" can connect.
    Make sure that "readers" can connect.
    Make sure that clients can post.
    "client" doesn't have the software needed to post.
    Introduction to the "newsfeeds" file
    The ME line in the newsfeeds file.
    How does the "ME" line interact with the other lines?
    Cookbook example of an outgoing NNTP feed.
    Cookbook example of an outgoing UUCP feed.
    Cookbook example of an outgoing UUCP-over-TCP feed.
    Testing an outgoing feed (your "newsfeeds" configuration).
    Other cron jobs.
    Cookbook example of setting up NOV ("overchan").
    How do I use nntplink with INN?
    How do I use newsgate with INN?
OTHER ERROR MESSAGES AND WHAT THEY MEAN:
    ld.so: Undefined symbol: _dbzwritethrough
    log file fills with "<site> <article-id> 436 No space"
    Why does my innd often die with the message "Can't sync history..."
    syslog message: ME cant sendto CCreader bytes 4 No such file
        or directory.
    syslog: cant symlink
    syslog: cant read Connection reset by peer
    inews says "bad message-id"
    Why do all these "readclose" messages show up in my syslog?
    "File exists writing symlinking article file -- throttling"
    "cant fopen <newsgroup>/.thread No such file or directory"
    news.daily reports: "Expire had problems removing articles"
    syslog: nnrpd[22560]: ? cant gethostbyaddr 198.3.24.3 Permission denied
    syslog: ME cant nonblock 15 Operation not supported.
    innd: ME cant update_active control
    syslog message: innxmit[1234]: max connect failed Error 0
    Can't open "/usr/local/news/shlock955", Permission denied
    INND: PID file exists -- unclean shutdown!
    cant fopen /usr/lib/news/distributions
    cant fopen /usr/lib/news/distrib.pats
    ME cant exec in /usr/lib/news/capture No such file or directory


=====================================================================
                   REASONS WHY INN ISN'T STARTING
=====================================================================

------------------------------

Subject:  What runs as what?

1.  The first "make install" MUST RUN AS ROOT.
2.  Other "make install" runs as "root", but sometimes "news" will work.
3.  "rc.news" runs as "root".
4.  "news.daily" runs as "news".
5.  ALL CRON JOBS (sendbatch, sendnntp, send-ihave, etc.) run as "news".

HOW TO REMEMBER THIS:
    EVERYTHING RUNS AS "NEWS" EXCEPT:
        "rc.news" runs as root, since it runs from rc.local (which
            runs as root) and since it runs things that start out
            as root but become "news" after doing special things.
        "make install" runs as "root" because it has to do "chown" to
          set up files securely.

------------------------------

Subject:  Why does innd just exit right away with no message?

First, fix your syslog: innd always logs a message before it exits.  (The
INN distribution includes a version of the current UCB syslog, along with
instructions on how to install it.  Ultrix systems might want to look at
the syslog that is available on gatekeeper.dec.com)

Second, the most common cause of this is that you do not have a history
file (or no history database).  You will see a message like this:

    ME cant dbminit /usr/local/news/history No such file or directory

This means that you do not have a history database (or no history.dir
and history.pag files).  If you are just installing INN for your first
time, you might want to run the BUILD script in your INN source tree.
Or, you can read about makehistory in doc/news-recovery.8; if you do
the latter, make sure to rename the database files (pay attention to
the two "mv" commands).


------------------------------

Subject:  syslog message: inndstart: inndstart cant bind Address already in use

>I try to start INN but got this error in my syslog file:
>       inndstart: inndstart cant bind Address already in use
>Can anyone give me a hint on how to fix it ?

Something else is already using port 119.  Comment out the line in
/etc/inetd.conf for port 119 and "kill -HUP" the inetd program (which
makes it re-read the configuration file).

Remember, there are two ways for programs to take control over an
incoming port.  (1) the program runs and grabs the port (which has to
be done as root) and then handles all incoming connections, or (2) the
program is listed in /etc/inetd.conf and inetd grabs the port and hands
off any incoming connections to the program specified in
/etc/inetd.conf (i.e. one process gets started for every incoming
connection.)

If you do (1) and (2) at the same time, the inetd will grab the port
and then anyone else that grabs the port will get an "Address already
in use" error.

INN's "innd" program is type (1).  C News+NNTP uses something that is
type (2).

Most people that get this error ran C News+NNTP a long time ago and
forgot to remove the line from their /etc/inetd.conf file.


------------------------------

Subject:  syslog message: ME internal no to group

If you set MERGE_TO_GROUPS to "DO", you have to have a "to" group
listed in your "active" file or you will get the above syslog message
and innd will not start.  You can edit the active file directly if innd
isn't running.


------------------------------

Subject:  syslog message: ME internal no control and/or junk group

You must have a newsgroup named "control" and a newsgroup named
"junk" for innd to start.  Since innd isn't running, you can edit
the active file directly

Add these lines:

control 0000000000 0000000000 y
junk 0000000000 0000000000 y

--tal

------------------------------

Subject:  syslog message: Can't setup communication (bind failure)

The message "Can't setup communication (bind failure) Permission denied"
means that the permissions on your _PATH_NEWSCONTROL directory
are wrong.  You might want to delete the directory and "make install"
to create it again.


------------------------------

Subject:  syslog message: ME bad_newsfeeds no feeding sites

(Rich Salz replies:) The syslog message is telling you that you are not
feeding news to any sites.  You have to have at least one feed.  (You
may consider this to be a bug, it's just that I'm too lazy to make
everything work right if you don't have any newsfeeds.)

Until you go into production and start feeding sites, add a line like this:
        dummy-feed:!*::


------------------------------

Subject:  syslog message: ME cant GetConfigValue

Jan 12 17:38:06 galaxy innd: ME cant GetConfigValue pathhost Error 0
                                                    ^^^^^^^^

This means you don't have "pathhost:" in your inn.conf.

GetConfigValue is the routine that gets data out of the inn.conf file.
If you get the above error, it means you don't have a particular value
in your inn.conf.  Run "inncheck -v" usually will tell you what you
need to do.


------------------------------

Subject:  syslog message: ME cant accept RCreader

Situation:  INN 1.4sec on ICS2.0 or Interactive Unix System V Release
3.2 or one of the many SVR4 Unix's.  You get syslog messages like:

Jul 14 12:07:44 isdn.IFNS.DE innd: ME cant accept RCreader No more
Jul 14 12:07:44 isdn.IFNS.DE innd: ME cant accept RCreader Protocol error
May  7 12:05:07 salyko.cube.net innd: ME cant accept RCreader Protocol error

when you connect to innd from a remote machine, but not from the
local host.

Problem:  Well, that's just another bug in the SVR4 networking code.

[e-mail] (Chris Munonye) reports that this patch fixed the
problem:

*** RCS/rc.c     Sun Jul 18 15:02:50 1993
--- rc.c Sun Jul 18 15:04:35 1993
***************
*** 173,178 ****
--- 173,181 ----

      /* Get the connection. */
      size = sizeof remote;
+     if (SetNonBlocking(cp->fd, FALSE) < 0)
+        syslog(L_ERROR, "%s cant un-nonblock %d in RCreader(errno %d) %m
: syslog entry:
+               LogName, fd, errno);
      if ((fd = accept(cp->fd, (struct sockaddr *)&remote, &size)) < 0) {
         syslog(L_ERROR, "%s cant accept RCreader %m", LogName);tocol err
         return;


------------------------------

Subject:  syslog message: ME cant ioctl(TIOCNOTTY) Invalid argument

Most likely a botched config.data - TIOCNOTTY is a BSDism and
probably doesn't work on SVR4-based system.  (If you aren't sure
if your Unix is SVR4-based, get out of the netnews business).


=====================================================================
                       THE DEBUGGING TUTORIAL
                (or, What do I do after Install.ms?)
=====================================================================


------------------------------

Subject:  Should I read the Install.ms file in its entirety before reading this document?

YES!  Install.ms tells you how to compile and install the software.
This document walks you through debugging the *configuration* of the
software once it is installed.

This document takes you from where install.ms leaves off, gives you a
quick overview of how all the pieces fit together, and then takes you
through specific debugging tasks.

Debugging INN problems is often difficult because one needs to be an
experienced netnews person to do it well.  You can only get experience
by having a properly running system.  This is a catch-22.  This
tutorial attempts to take you through the basics.  The rest you'll
figure out.

Newsgroups you should know exist:
news.software.nntp  -- INN questions go here.
news.software.b     -- Discussions about any of the many software
    packages that support the "B news" format (i.e. INN, C news,
    ANU-NEWS, etc.)

This document also takes you through the process of verifying that your
system is properly configured.  When you are done, you should:

1.  be sure that when feeders connect they are treated as feeders.

2.  be sure that when clients connect they are treated as clients.

3.  be sure that posting works.

4.  be sure that your out-bound feeds are properly configured.


------------------------------

Subject:  Terminology used in the rest of this document.

We will pretend that your machine is named "nntphost" or
"nntphost.do.main" and that there is a client named "client" or
"client.do.main".

Some machines connect to you to try to feed you new articles.  We'll
call these machines "feeders".  Some machines try to connect to you to
read and/or post articles.  We'll call these machines "readers".


------------------------------

Subject:  How does it all fit together?

Here is a fantastic overview of the workings of INN.

From: Ken Hornstein <[e-mail]>

I discovered that the biggest problem I had with INN was understanding how
everything fits together (since I had no experience with B or C news).
Here's a (hopefully) simple description of how everything fits
together:

After running rc.news (as "root"), you should have the "innd" daemon
running ("ps" will show the process to be owned by "news").  This is
the Master Daemon.  It handles incoming connections, stores the
articles on your disk, but does _not_ send any articles out itself.  It
directs other programs to do that.  Exactly where articles are sent and
how they are sent is determined by the "newsfeeds" file.  Setting up
your newsfeeds file will be the hardest part of configuring INN.  Here
are some example entries from my newsfeeds file:

ra/ra.nrl.navy.mil\
        :*,!psu.*/!psu\
        :Tf,Wnm:

Looks complicated?  It isn't.  Here's what it means:

"ra" is the name of the feed.  "/ra.nrl.navy.mil" is an alias for ra.
This is important because INN uses the "Path" header to insure the
articles are not sent to sites where they have already been.  Thus, any
article that has "ra" or "ra.nrl.navy.mil" in the Path header will NOT
be sent to this site.  We know that no other site inserts "ra.nrl.navy.mil"
because it is a FQDN (Fully Qualified Domain Name).  We know that no
other site inserts "ra" because it is registered in the UUCP Maps.
(Ok, "ra" isn't registered so I'm just taking a small gamble.)

The second line tells what articles will be sent out to this site.
"*,!psu.*" means that articles for (all newsgroups minus those that
match "psu.*") will be sent to ra.  The details of the pattern matching
is found in the wildmat(3) man page.  The "/!psu" means that articles
with a "Distribution" header of psu will also not be sent to ra.

The last field specifies exactly what _kind_ of feeds.  "Tf" means this
is a file feed.  Unless you have unusual requirements, all of your
feeds will be file feeds.  "Wnm" means that the relative path name and
the Message-ID of the article will be written to this file.  The "n"
means "relative path name", the "m" means "Message-ID of the article".
The newsfeeds(5) man page explains all the letters you can use with
"W".  By default, the output file is called the same name as your feed
file, and is in your out.going directory.  So on my system, every
article destined to ra will have its filename and Message-ID written to
the file "/var/spool/news/out.going/ra".

So how do the articles actually GET to ra?  You run a program that
reads the feeds file and transmits the article.  Two such programs are
included with INN -- "send-nntp" and "nntpsend".  My personal
preference is for nntpsend.  If you are going to use nntpsend, you will
need to add a similar line to your nntpsend.ctl file:

ra:ra.nrl.navy.mil

This tells nntpsend that articles in the feed file "ra" should be sent
to the site "ra.nrl.navy.mil".  I run nntpsend out of cron every 10
minutes with this line:

(in "news"'s cron)
0,10,20,30,40,50 * * * * /usr/local/news/bin/nntpsend

Or, if you use an old-style cron (like Ultrix does):
0,10,20,30,40,50 * * * * /bin/su news -c '/usr/local/news/bin/nntpsend'

UUCP feeds work similarly and are described in a different section.

As each article comes in (note that hosts feeding you _must_ be listed
in the hosts.nntp file), innd will examine it and distribute to your
listed feeds based on the above-described selection criteria.

Another important thing to do is to make sure your articles get
expired.  This is done from the "news.daily" script.  The "expire.ctl"
file describes how long you want each article to last.  Here are some
sample lines from my expire.ctl:

/remember/:14

This line tells expire to keep history entries for articles at least 14
days.

*:A:1:7:21

This is the default line.  This says that by default, an article is
kept a minimum of one day, the default expiration time is 7 days (this
applies if there is no "Expires" header), and the very maximum that the
article is kept is 21 days.

psu.*:A:1:14:28

This line applies to groups only in Penn State.  By default, those
articles will last 14 days, 28 days at the most.

Note that lines in expire.ctl should have the most general entries
first, with the most specific entries last.

Lastly, where do newsreaders fit in?  When a newsreader connects to the
innd process, it sees that this is not a feeder (the hosts.nntp file
lists only sitest that feed YOU) so it forks a nnrpd process and hands
the connection to it.  This way innd can concentrate on newsfeeds.
Some newsreaders don't open a connection, but instead read the articles
out of "/usr/spool/news" (and gets meta data from "/usr/lib/news").
INN doesn't need to do anything about those readers except to make
sure the right data is where they expect it.


------------------------------

Subject:  What should I monitor as I debug INN problems?

1.  run "tail -f /var/adm/messages" to see if any syslog messages are
being generated.

2.  run "tail -f /var/log/news/news.err" to see if any fatal errors
happen.

3.  Check for incoming email constantly (especially when trying to post
from "nn").


------------------------------

Subject:  My innd won't start!

Keep a "tail -f /var/adm/messages" running.  INN reports most errors
via syslog.  The syslog messages usually explain what is wrong.
Elsewhere in this document are details about some of the less obvious
syslog messages.

Chances are, INN is starting, finding a misconfigured "ME" line in the
newsfeeds file, and exiting.  You might want to read the section on
configuring your "newsfeeds" file first.

Rich Salz says a common reason is that you ran makehistory but didn't
rename the DBZ files.  "makehistory" generates history.n.dir
and history.n.pag.  They must be renamed:
    mv history.n.dir history.dir
    mv history.n.pag history.pag
(In the future, you could run "makehistory -f history", which is a
little more risky... so read the man page before you use it.  Until
1.5, "makehistory"'s man page was part of "news-recovery".)

Izar Tarandach <[e-mail]> suggests that another common
mistake is that innd wasn't being started by the correct uid.  innd
(and therefore rc.news) must be started from "root" (not "news").  It
immediately turns itself in user "news" once certain tasks are
completed.

If you use a suid root inndstart, you can run it as any user.


------------------------------

Subject:  Connecting to a TCP/IP server.

You know that "telnet"'ing to a machine lets you log into it.  You are
actually connecting on the "telnet" port (port 23).  Many TCP/IP
services allow you to "telnet" into their port and talk directly to
them.  Try "telnet nntphost 21".  This means log into port #21 (the
"ftp" port) instead of the usual remote login port.

Once you are in, you'll get no prompt.  Type "help" and press RETURN.
You should get a list of commands.  If you know what the commands are,
you can talk to this server.  Type "quit" and press RETURN to get out.

After every command you should get some kind of status message.  Each
line will begin with a number.  Each message has a unique number.
Errors are defined as anything that starts with a number >= 400.
Positive (non-error) messages are <400.

SMTP (mail) and NNTP (netnews) work the same way.  Telnet into their
port and issue commands and data.  "quit" always gets you out.

We'll use this to debug INN configurations by "telnet"'ing into the
innd server and seeing the raw error messages it gives us.

Try "telnet"'ing into the NNTP port (#119) of a working NNTP server to
see what it's like.


------------------------------

Subject:  Make sure that "feeders" can connect.

"feeders" are listed in hosts.nntp.  "readers" are listed in
nnrp.access.  This section deals with "feeders" and hosts.nntp.

When a machine connects to the NNTP port of nntphost, it connects to
the innd process.  innd knows the internet address of the machine that
is making this connection, and sees if it matches the internet
addresses many of the machines listed in the hosts.nntp file.

If the machine is not listed in hosts.nntp, it is assumed that this
machine is not a "feeder" and forks off a nnrpd to handle this
connection as a "reader".  If you didn't know that, you didn't read
enough of the INN installation documentation.  Go back and read it
now.

Read the man page hosts.nntp to get a complete understanding of what's
going on.  nnrpd uses its own authentication scheme, which is
described in the next section.

Since I know you didn't read that man page, I'll give you one more
chance to read it now.

Let's configure hosts.nntp.  Just enter the names of all the machines
that feed you:

feeder1.do.main:
feeder2.do.main:

I don't use passwords yet.  If you do, add them after the ":".

Now let's test to see if the feeder can connect properly.

Log into to the feeder and "telnet nntphost 119".

If you can't log into a feeder, configure your own machine as a feeder
(i.e. feeder to itself) for testing purposes.  Once you can see that
INN is treating that machine as a feeder you can replace the machine's
name with the name of a real feed.

If you are given an error message and booted out, check the error
message to see what's wrong.  Maybe the machine is running maintenance
at the time and you have to try again later.  Maybe the machine doesn't
recognize you at all and you have to edit "hosts.nntp" (and don't
forget the "ctlinnd reload hosts.nntp" command!).

Run "inncheck" to tell you if you have made any obvious mistakes.

If your "history" file or other files have the wrong ownership or
protections INN will mention the offending file in the error message.
Another common mistake is that people try to use wildcards in
hosts.nntp (which is not supported).  Remember, there are very few
machines that you consider to be "feeders", so you don't want to use a
wildcard.

To test a "feeder":  If "feeder1" can send an "ihave" command and get a
"335" as a response, you know that "nntphost" is permitting "feeder1"
to transfer news as a "feeder".  "ihave" requires an operand.  I
usually type "ihave <1@test>" and press RETURN.  "<1@test>" is a
Message-ID that I know doesn't exist.  If I get "500 What?" I know that
innd assumed that I'm a "reader" (so I have to edit my "hosts.nntp"
file and add this client).  If I get "335" and then a blank prompt,
then INN is expecting to be fed an article.  I usually just "^]"
(control-]) and "quit" out; I know that it was willing to accept the
article.  If I get some other error message, it usually gives me enough
information to debug the problem.


------------------------------

Subject:  Make sure that "readers" can connect.

As I wrote before, if a connection comes from a machine that isn't
listed in the hosts.nntp file, it is assumed to be a "reader".  A
"feeder" can also issue the "mode reader" command to become a
"reader".  If you have "telnet"'ed in as a "feeder", try issuing this
command.

Note: If a site is going to feed *and* read, you'll have to link
readers with innd's client library. The reason for this is that the
clients must tell innd that they want to read using the "mode reader"
command.  The library does that automagically.  It is rare that you
have a machine that is a reader and a feeder (since people will want to
read on their local machine, not yours.)  News readers are now
being packaged as "INN ready" so this will be less and less of a
problem.

Once the connection has been handed off to nnrpd, nnrpd checks to make
sure you are authorized.  It does that by reading the nnrp.access
file.

There is a problem with what you enter in that file.  Namely, I might
call the client machine "client", but that doesn't matter.  What
matters is what "nntphost" thinks "client" is called.  Maybe "nntphost"
thinks its name is "client.do.main" or even "137.202.177.3".  It
doesn't matter what *you* call "client", permissions in the nnrp.access
file have to be specified based on what "nntphost" calls "client".
Technically, nnrpd uses gethostbyaddr() to reverse-lookup the name.
gethostbyaddr() uses DNS or, if you are on a brain-dead Sun running
Sun's NIS/DNS hack, it uses NIS, or DNS, or whatever the hell Sun was
thinking when they created that cruft.

To find out what "nntphost" thinks your machine is called, do the
following:  Telnet from "client" to "nntphost" and execute the "finger"
command (just "finger" alone on the command line).  The last column is
what "nntphost" thinks your machine is called.

If you don't have an account on both machines things are more
difficult, consult your NIS or DNS expert to tell you what the answer
would be.

There is one exception to this technique.  If you are using SunOS and
braindead NIS you get just the machine name (like "milk") instead of
the FQDN (like "milk.warren.mentorg.com") then you must tack on a
period then the domain of the machine.

So, with this knowledge (what your nntphost think's client's name is)
and a copy of the man page, edit nnrp.access and add "nntphost"'s name
for "client" to the file.  Unlike hosts.nntp, nnrp.access can have
wildcards (for example, "*.sjc.mentorg.com").  You'll want to include
wildcards for all the domains that should be allowed to read/post.

Here are some decent examples from my nnrp.access file:

-------------------------------------- Tom's nnrp.access file START
## Default is no access, no way to authentication, and no groups.
*:: -no- : -no- :!*
*.mentorg.com:Read:::*
*.mentor.com:Read:::*
*.warren.mentorg.com:Read Post:::*
-------------------------------------- Tom's nnrp.access file END

The second field of "nnrp.access" is case sensitive.  "read post" does
not mean the same as "Read Post".  If you know this already it's
because you read the man page.

Note:  nnrpd will append the domain to a name that is not a FQDN.
There is no need to try to find a wildcard that will match non-FQDN
names (i.e. machines in your local NIS cluster).  Previously this FAQ
had reported that "*[^.]*" would match these short names but that was
wrong (the wildcard matches everything, oi!).  nnrpd turns non-FQDN's
into FQDNs.

After you change "nnrp.access" you don't have do "ctlinnd reload" since
the file is read by each nnrpd as they start up.

Now "nntphost" should be letting "client" read.  Let's test this out:

Log into to the reader and "telnet nntphost 119".

To test a "reader":  Give the "mode reader" command and see how it
it goes.  If it doesn't give an error, then nnrp.access is letting you
through.  To read an article (or just get the header) type "head
<2@test>" and press RETURN.  Again, "<2@test>" is a message-id that I
know doesn't exist.  If you are allowed to read at all, it will tell
you that it can't find that article.  You should try the command with an
message-id that you know exists and make sure you see the article's
header.

If reading works you can skip to the next section.  The rest of this
section helps you debug reading problems.

If "mode reader" gives an error (and rudely disconnects you) then you
have a typo in nnrp.access OR you didn't issue the "ctlinnd reload"
command correctly (or at all) OR nntphost thinks that "client" is
called yet something else OR innd can't exec nnrpd for one reason or
another -- see the syslog output or the innd.err log file.  Check all
of those things then go to the beginning of this section and start
over.

Note: Some telnet implementations are Real Stupid and disconnect you
before showing the error message.

You can also run nnrpd by hand if you have
    stdin:Read Post:::*
in your nnrp.access file.  Just run nnrpd and type interactively.  This
is useful for making sure it's compiled right.


------------------------------

Subject:  Make sure that clients can post.

The "inews" command (usually in /usr/local/bin) takes a post from a
user, adds any missing headers, appends the file
"~/.signature" (see below), and possibly replaces any headers that
are obviously forged.  "inews" will also reject a message if the
message is seriously botched.  "inews -h" expects a post on stdin
beginning with headers, then a blank line, then the body.  "inews -h
-D" doesn't post the message, but outputs what it would have posted.
The minimum headers one can feed is "Newsgroups:" (which is plural) and
"Subject:" (which is singular).

The "~/.signature" handling has some specific rules:  INN's inews exits
with an error if ~/.signature is (1) more than 4 lines long, (2)
exists, but is not readable, or (3) is longer than 4k chars.  inews
exits with an error (rather than silently reading only the first 4
lines) to avoid a flurry of posts asking, "Why did my .signature get cut off?"

By the way, a header looks like "Header-Name: data".  That is, after
the header name there is exactly one colon then exactly one space.  The
space is a space, not a tab.  Another picky detail is that list of
newsgroups on the "Newsgroups:" line is a comma separated list, with no
spaces.  There are no spaces before the colon.  If there is nothing
after the colon or if there is only whitespace after the colon then
that header will be removed by "inews".  Sites that don't remove such
"empty" headers have broken software.  Get it?  Got it?  Good.

Here's the test message I constantly use:
------------------------ cut here 8<
inews -h -D
Newsgroups: foo.test
Subject: test of inn posting

this is a test
------------------------ cut here 8<

Exciting huh?

You might also use the 'feedone' program in the frontends directory.
Do "cd $inn/frontends ; make feedone" to get it built.  To run it, do

        feedone -t -r /tmp/inews.input

This will (-t) trace all I/O with the server and (-r) use a random
message-id each time.  If you want to test posting from a newsreading
host (i.e., one that connects to nnrpd and uses the POST command) use
the -p flag.

If inews was able to get to the /usr/lib/news/inn.conf file (for
defaults) you should get a nice post on your screen.  If you don't,
here are my suggestions:

1 -- You have an old inews from C news or B news laying around
2 -- inews will give you an error message saying what's wrong.

You might want to look around the usual places to make sure that there
are no old versions of "relaynews" or "inews".  People trying to use
the "inews" from C news will get a message about "can't open
redirection" or similar.  Make sure they are running the programs
included with INN.  There is something called "mini-inews" which should
just take a post and send it to the nntp server.  Delete that and
replace it with INN's inews.  INN's inews is mini-inews and regular
inews, it is the ying and then yang of inewses.  It is the one true
inews.  It is the one inews to end all inewses and all others are false
idols.

Note:  False idol worshipper and heathen David Myers <[e-mail]>
reports that mini-inews works fine.  He stays with mini-inews...
"because INN inews needs to access not only inn.conf, but moderators,
too.  Installing and maintaining these files in a ~1000 client,
multiple administrative domain setup like ours is too much of a pain.
Most (all?) of the work done by INN inews is done by in.nnrpd during
posting, anyway."

Kenji Rikitake <[e-mail]> reports:
"Keep in mind that INN inews refers to many environment variables.
Beware of _inherited_ variables especially when you do su to maintain
your news server.
I got trapped and wasted a day with NNTPSERVER.  I tried to post to a
local newsgroup, and inews kept refusing it and sending me 'no such
newsgroups...' error message.  I finally found out that inews was
looking up a wrong server, _implicitly_ specified by
'setenv NNTPSERVER ...' in my .login script.  It took a day to find
such a subtle misconfiguration, after a whole recompilation of entire
INN kit, active and history rebuilding, and all possible configuration
checking.  *sigh*"

"inews -h" sometimes reports: 'Warning, can't connect to server'
What server is it trying to connect to?  Remember, inews uses
the NNTPSERVER environmental variable and (if that isn't set) looks
in /usr/lib/news/inn.conf.

INN's inews sometimes prints the error: "Can't get list of newsgroups,
No such file or directory.".  inews called CAlistactive() to get a
local copy of the active file.  If it can't reach the active file you
get this error.  Look at your PATH_TEMPACTIVE and see if it makes
sense; i.e., if it is a valid /tmp directory.

"inews -h" sometimes reports:
    Can't send article to the server:
    441 480 Transfer permission denied
This means that you set HAVE_UNIX_DOMAIN to DONT and you don't have
your news server in its own hosts.nntp file.  (nnrpd gets a POST,
connects to innd over a TCP socket and sends an IHAVE.) (thanks to
Chris Jackson <[e-mail]> for pointing this out).  Add your news
server's name and "localhost" to hosts.nntp and do "ctlinnd reload
hosts.nntp".  (for the reason why, read "Warnings to people that must
set HAVE_UNIX_DOMAIN to DONT")

"inews -h" sometimes reports:
    Warning Text unavailable -- Article will be spooled.
This means that inews could not connect to the server, but errno
had nothing useful, and no reply came from the server.  "It just
didn't work."

If it still doesn't work, look through your syslog to see the name
of the host that innd got, and why it handed off to nnrpd.  Perhaps
there is a DNS/NIS/hosts-file mismatch.  (suggested by Rich Salz)

Other problems are usually the result of not being able to find the
"inn.conf" file (copy it to the client or make it available via NFS) or
you are using Sun's brain-dead NIS/DNS stuff which doesn't do reverse
name lookups well.  If inews tells you that it can't generate a
Message-ID, this is because it can't figure out your domain (which is
used in making the message-id string).  Force it to know your domain by
adding a "domain:" line in "inn.conf".  Solaris 2.x users will get a
"can't generate message-id" error if they didn't follow the advice
about getfqdn.c mentioned in another part of this FAQ.

If you get something like:
    500 "GROUP"" not implemented; try "help".
This implies that the client host is in hosts.nntp, not nnrp.access.
However, if you need to have this machine in in the hosts.nntp file
(i.e. it is a feeder or you have an operating system that requires you
to set HAVE_UNIX_DOMAIN to DONT) then your newsreader must send a "mode
reader" to the server when it connects.

Once you get "inews -h -D" working, do the same test without the "-D" option
and let it actually post the message.  If it can't post, it will tell
you why.  If the answer isn't clear enough, "telnet nntphost 119", give
the "mode reader" command, then the "post" command.  Enter lines of
text like you would to "inews -h" and then type "." on a line by itself
(and press RETURN).

If posting via "telnet nntphost 119" DOES work and posting via "inews -h"
DOES NOT work, you know that (1) "inews" is compiled wrong, or more likely,
(2) you aren't using INN's inews.  Either way, if this is happening
you know you have narrowed your problems down to the inews program.

By the way, posting to misc.test is pretty useless considering that the
entire world doesn't need to see your message.  Post to a local
newsgroup or even a state-wide newsgroup like "nj.test" (assuming you
are in New Jersey).  There are lots of people that reply to every test
message they see, so expect to get tons of stupid email.  (though, if
you don't get any email consider yourself lucky).  Also, there is no
newsgroup called "news.test" so don't post there.  Many try, try fail.
By the way, if you are one of those people that reply to every test
message they see, get a real hobby.  The convention is that replies
are not sent to test messages with the word "IGNORE" in the Subject:.

Do *NOT* post your test message to a non-test newsgroup.  You will get
many angry replies from all over the world.  ...including the FAQ maintainer.

Look at the posted message in the news spool (if you post a message to
nj.test, "cd /var/spool/news/nj/test" and cat the highest numbered file
you see).  If your site name is listed multiple times in the "Path:"
header, put your server's name on the "pathhost:" line of "inn.conf"
and recompile INN with "INEWS_PATH" set to "DONT".  (I don't know why
Rich likes that as the default!)

REMEMBER:  inn.conf is read into innd only once.  After it is changed,
the innd daemon must be shutdown and restarted.  (use "ctlinnd shutdown x"
and then run rc.news as root).

If "inews -h" posts a message, smile because most of the battle is over.


------------------------------

Subject:  "client" doesn't have the software needed to post.

If the client doesn't have "inews" at all, copy it from the server (if
they are compatible machines) or check the INN installation manual to
find out how to compile just the client programs for a machine.  There
is a special gimick included with INN to compile inews for the various
other OS's and versions of Unix without having to compile the entire
INN package.

Since nnpost, Pnews, postnews, and all other news posting software
shouldn't do anything but ask for header information, let you add a
body, and then pipe the whole thing to "inews -h", you can be pretty
certain that if "inews -h" works, your news posting programs will
work.  Think again!  Post from each of them and make sure they all get
posted.  You might find that they access a copy of "inews" that was
part of C news, mini-inews, or heavens knows what.

I highly recommend that people use "find" or "gnufind" to seek out and
replace all old versions of "inews" with symbolic links to the one
"official".

Something like:

gnufind / /usr /usr/local /usr/lib -xdev -follow -name inews\* -print

Then, for every file found, do the following:

mv inews inews.cnews
ln -s /usr/local/bin/inews inews

Now you only have to update /usr/local/bin/inews, rather than
chasing may copies.

"nn" and "nnpost" create a file called "~/.nn/params" right before you
post with tons of useful information.  While posting you can shell out
of the editor and view the file.  The file is deleted after the message
is posted.  I had to view this file while shelled out of my editor to
find which "inews" was being used by "nnpost".

It's also a good idea to check your mail now and then while you are
doing this.  Some newsreaders (like "nn" notify you of a posting
problem via mail.

On non-INN systems, "inews" returns pretty quickly.  Actually they fork
a process to do the actual posting in the background.  When those
"inews" return, you don't know if the post was successful or not.
These "inews"'s have a "-W" option which turns off this forking feature
(i.e. Wait for the post to complete).

INN's "inews" never forks because the wait is never that long.  When
"inews" returns you know if the post was successful or not.  INN's
"inews" accepts the "-W" option for compatibility.

This may seem obvious, but when posting a test message, consider
including the machine you are posting from and the program you are
using.  Even though you may check to see if the message got posted
after every test, this will help you later when you go back to see what
you have done.


------------------------------

Subject:  Introduction to the "newsfeeds" file

Outgoing news is controlled by the "newsfeeds" file.  The INN 1.2 man
page for this file is a bit complex.  The man page in 1.3 (and beyond)
gives better examples.  Here's a "cookbook" of examples that should
cover most of your needs.  Debugging tips are also included.

Always remember that newsfeeds uses "wildmat" matches, not the
semi-regular expressions that C news uses.  This means that if you want
to get comp.foo and the subgroups under it (comp.foo.bar, comp.foo.baz,
etc.) you have to use a statement like:

comp.foo,comp.foo.*

OR

comp.foo*

BUT NOT

comp.foo.*

However, "comp.foo*" will match "comp.foobar", as well as
"comp.foo.bang".


------------------------------

Subject:  The ME line in the newsfeeds file.

The "ME" entry is a bit confusing.  Be careful when you
read the man page.

Here is the "ME" line that I use in my "newsfeeds" file.  I find
it works quite well, but you might want to remove the distributions
that you don't need (i.e. New Jersey).  Since my site has clients
reading from all over the world I try to have every distribution I
can find.  However, I hear of a new distribution almost daily so this
list is always changing.

ME:!*/\
news,gnu,comp,biz,alt,rec,misc,sci,soc,talk,inet,world,worldwide,all,\
aus,su,uk,york,eunet,na,can,qc,tor,us,usa,mn,oh,chi,ca,ba,tx,pnw,il,ne,\
ny,nyc,phl,bl,nj,warren::

If you want to blindly accept all distributions, try this:

ME:!*::


------------------------------

Subject:  How does the "ME" line interact with the other lines?

> I'm still a little confused about the ME line's second field.

The man page as of INN 1.3 is much more clear on this.  Basically, the
second field of the "ME" line specifies the default for the rest of the
feeds.  Otherwise, it isn't used.  The "active" file declares which
newsgroups you accept and don't accept.

Here are some examples:

ME:!*:::
foo:!junk:...        --send no newsgroups

ME:*:::
foo:!junk:...        --send all newsgroups except junk

ME:!*:::
foo:*,!junk:...      --send all newsgroups except junk

By the way, generally you do not want to send "junk" or "control*" to
your neighbors.


------------------------------

Subject:  Cookbook example of an outgoing NNTP feed:

This example involves a machine named oddball.mentorg.com, that has an
alias of oddball.sjc.mentorg.com, which should receive all posts (but
control & junk should never be passed on) and not certain
distributions.  Add the following line to newsfeeds:

oddball.mentorg.com/oddball.sjc.mentorg.com:*,!control*,!junk/!local,!warren:Tf,Wnm:

Have the user "news" run the following via cron:

3,23,43 * * * *  /usr/lib/news/bin/nntpsend >/dev/null 2>&1

(this only needs to be added once.  nntpsend refers to a file
called nntpsend.ctl to find out what to do).

Add the following to nntpsend.ctl:

oddball.mentorg.com:oddball.mentorg.com::

Done!


------------------------------

Subject:  Cookbook example of an outgoing UUCP feed:

Example:  A site named "plts" that can not get the "clari" newsgroups
or distribution "warren".

Add the following to the newsfeeds file:

plts:*,!clari.*,!junk*,!control*/!warren:Tf,Wnb:

Add the following to the cron tab (as user "news"):

0 0-5,16-23 * * 1-5       /usr/lib/news/bin/sendbatch -c plts >/dev/null 2>&1

NOTE: I know that "plts" is unique and won't conflict with
some other site named "plts" because it is registered
in the UUCP Maps (see comp.mail.maps).

If your feeder is sending you netnews via UUCP (which is usually the
case, since it isn't useful to just feed articles and not receive any)
you must configure your UUCP to allow the remote system to execute
rnews.  Your UUCP documentation should tell you how to set up a UUCP
connection and how to change the allowed commands.  That means that
uucico will execute /bin/rnews on every incoming batch.  INN comes with
a perfectly servicable "rnews" program that can handle all the standard
batched and compressed news formats.  The INN rnews will uncompress and
unbatch as necessary and then pass each article to innd for
processing.  (Thanks to Jerry Aguirre <[e-mail]> for
this paragraph)


------------------------------

Subject:  Cookbook example of an outgoing UUCP-over-TCP feed:

[e-mail] (Jerry Aguirre) writes:

People ask about this like it was something exotic requiring special
setup.  Kind of like: "I know how to use a wheel barrow and I know how
to shovel sand but how do I shovel sand in a wheel barrow?"

Step 1:  Set up a UUCP/TCP connection between you and the destination
site.  How?  Read your UUCP documentation.  If your machines's UUCP,
and the desitination machine's UUCP both supports UUCP/TCP then it will
be documented.  If not then get a better version of UUCP.  For example,
Taylor UUCP.

Every OS sets up UUCP differently:  YOU HAVE TO READ THE DOCUMENTATION.

The point is to get the UUCP/TCP link working before even thinking
about sending news over it.  This is true of any news feed over UUCP;
even dialup.  Try using "uucp" to copy some scratch file to the other
end.  When you have that working then you are ready for the next step.

The only "gotcha" here that I can think of is that the destination host
may not be accepting UUCP/TCP connections.  Before wasting your time
trying to debug do a "telnet destination.host.name uucp" and see what
happens.  If the connection is accepted and you see a "login" banner
then it is ready for you.  If not then ask the admin of that site to
enable UUCP/TCP.  This is typically done by uncommenting it in
/etc/inetd.conf and -HUPing inetd (on REAL versions of Unix).

Step 2.  Set up a standard compressed news feed to the UUCP name of the
destination site.  How?  Read your news documentation.  Setting up UUCP
feeds is a standard, documented, procedure.  In this FAQ you'll find it
in "Cookbook example of an outgoing UUCP feed".  Doing compression is
nothing special, it's part of the procedure you would be doing anyway.
It's either a flag or a slighly different command.  The news system has
NO knowledge that this is UUCP/TCP.  For all it knows this is a
standard dialup connection.  In fact is is possible to have the UUCP
connection fall back to dialup if the TCP connection fails.  The news
batching software just doesn't care.

The only variation here I can think of is to make the batch size bigger
than the default.  The 50K default was picked back in the days when
modems were 1200 BPS (or even 300).  It is no longer appropriate for
todays 9600 BPS or faster connections.  Using a bigger batch size cuts
down on dead time in the connection and lets compress do a better job.
I would go to at least 200K batches.

Now maybe it would be nice to have a "cookbook", step by step, set of
instructions on how to do this.  But UUCP seems to vary a bit between
different versions so what might work at one place would be useless at
another.  And setting up the news feed is going to be different between
the different versions of news (B, C, and INN).

I suggest that if people are having trouble setting up a UUCP/TCP
connection that they post their configuration to the net and ask how it
is done on their versions of Unix and UUCP.


------------------------------

Subject:  Testing an outgoing feed (your "newsfeeds" configuration).

Here is a decent game-plan for testing your newsfeeds configuration:

Suppose your site is in New Jersey and you have a distribution called
"mentorg" which should be used by people that want to make sure that
their post will not leave their company (Mentor Graphics).  You should
do a test post to "nj.test" with no "Distribution:" header, and with
"Distribution: nj" and "Distribution: mentorg".  After posting, do a
"ctlinnd flush ''" and make sure that the /var/spool/news/out.going
files for all your sites did/didn't queue up those three messages as
appropriate.

IMPORTANT:  Remember to do a "ctlinnd reload newsfeeds x" command every
time you update your "newsfeeds" file!

Finally, for checking out changes to newsfeeds, I've found "ctlinnd
checkfile" handy.   "inncheck" will verify that most of your
configuration is sane.


------------------------------

Subject:  Other cron jobs.

Once a night you should run the "news.daily" script which will
expire old articles, run the daily reports, etc.  It should run
as "news" and look something like this:

40 23 * * *               /usr/lib/news/bin/news.daily delayrm

You should also have a line like this:
20 * * * *                /bin/rnews -U

This processes any batches or posts that came in while innd was down.
(i.e. when users post and get a message like, "Server down, spooling
locally" this command picks up those files and posts them).  It can't
hurt to run this more often, but once an hour should be fine.


------------------------------

Subject:  Cookbook example of setting up NOV ("overchan").

Now that you have your other feeds working, you might want to set up a
NOV feed so that your NOV database is built.  Newsreaders use the NOV
database to speed up their queries.

[e-mail] (Christophe Wolfhugel) (with
many modifications from Tom Limoncelli and further input from
[e-mail] (Dave Kennedy) ) writes:

Step 1:  Upgrade to INN 1.4 or higher:  Most of the bugs in 1.3 were
related with overchan.  In fact, the only reason why many people used
1.3 without any problems was due to the fact that they were not using
overchan (and they didn't hit on some of the bugs that appeared for
SVR4 users, all of which were fixed in 1.4)

Step 1.5:  Make sure _PATH_OVERVIEWDIR in config.data is NOT set to
"/var/spool/news".  There is a big performance boost to be realized by
putting the NOV files outside the /var/spool/news hierarchy.

To find out why, read "Subject: overchan can't keep up." in part 3 of
this FAQ.  You might want to read this anyway since it gives advice
about other things to do to get better NOV performance.

"/var/spool/news/over.view" is becoming the standard place to put put
your ".overview" files.  If you do not use this location, make
/var/spool/news/over.view a symbolic link to the correct place.  For
performance reasons, it is a good idea to set _PATH_OVERVIEWDIR to the
actual location of the files.  NB:  if you change config.data, you must
do a "make all" and "make install".

Step 2:  Make sure INN is working.  Get everything else working before
you try to get overchan to work.  You'll only confuse yourself.

Step 3:  Ponder if you have enough disk space.  NOV uses up an
additional 10%-20% of your news spool.  This is a good 100 Mb if you
have a full feed.  The real space savings come when you delete your
separate databases for trn, nn, and tin and use one unified database.
All serious newsreaders have NOV support.

Step 4:  Edit "overview.fmt" (it's in the $INN/site directory, or you can
edit it where it was installed, in /usr/lib/news ) to include
"Xref:full" as the last line.  (i.e. uncomment out the last line).

Step 5:  Add this entry to your "newsfeeds" file.  overchan gets it's data
from a special feed.

# This feeds header data to NOV:
OVERVIEW!:*:Tc,WO:/usr/local/news/bin/overchan

Read the "newsfeeds" man to make sure you understand what you've
just done.  Do a "ctlinnd checkfile" to make sure the newsfeeds
file has the proper syntax, then do a "ctlinnd reload newsfeeds nov"
to make it official.

Step 6: If you changed your $inn/site files, then:
    % cd $inn/site
    % make install

Step 7: Let innd know that files have been updated:
    % ctlinnd reload overview.fmt "Enabled XRef:"
    % ctlinnd reload newsfeeds "Added OVERVIEW - overchan entry"

Step 8: You must run "expireover -s" at least once a month.  Once a
week is even better.  Otherwise, entries for cancelled articles will
never be removed.  Here is a good crontab entry for "news" to run:
0 5 * * 1 /usr/lib/news/bin/expireover -s


Step 9:  (optional) To create the original database:

    (run this as "news")
    % /usr/local/news/bin/expireover -a

This step will take a long time depending on the number of articles
already in your system.  But, if you skip this step, client access
will be slow for articles that came in before you started "overchan".
This is not a serious problem; you will get a lot of warnings in your
"news.daily" output until you have received at least one new article
in each newsgroup.

Note:  "a lot of warnings" means one for every newsgroup.  This can
make your news.daily report >6000 lines.  The lines will all look like:

overchan cant open clari/local/washington/.overview, No such file or directory
overchan cant open clari/local/sfbay/.overview, No such file or directory
overchan cant open uc/news/.overview, No such file or directory

Step 9:  Change the invocation of news.daily:

In the crontab file for "news", edit the "news.daily" line to be
something like:

   news.daily delayrm expireover

(the expireover is required if you use overchan)

Step 10:  Inform your users that you now support "NOV, the News OverView
database" and suggest that people switch to newsreaders that use
newsreaders that are compliant with the Overview format.

Step 11:  You are done.

Step 12:  In a few weeks, drop support for mthreads, nnmaster, etc.
(assuming you've upgraded to replacements that use NOV).  Delete all
those old databases that might have been maintained and enjoy the newly
gained functionality and regained disk space!


------------------------------

Subject:  How do I use nntplink with INN?

First of all, I don't personally recommend using this program.  I feel
that it is a gimick.  However, if you decide to join the INN Instant
Party, I suggest that you first run the feed using nntpsend (included
with INN) FOR AT LEAST A WEEK.  Once you are confident that functioning
properly, consider to switching to nntplink ONLY IF:

    1.  You have more than 3 outgoing feeds.
    2.  You have gobs and gobs of real memory.
    3.  Your OS has a superior mmap() & disk IO system (like SunOS)

If you decide to switch, here's a cookbook example of an newsfeeds
entry using nntplink:

PLEASE make sure traditional "nntpsend"-style feeds work reliably
before you switch to nntplink.

netcomsv.netcom.com\
    :*,!junk/!ParcPlace\
    :Tc,Wnm,S1024:/usr/local/news/bin/nntplink -i stdin netcomsv.netcom.com

INN 1.2 users should have an explicit S value (i.e. S1024 or S16384).
Without it innd 1.2 can choke and lose data if the receiver is jammed.
(fixed in INN 1.3).

The latest version of nntplink is available from
shape.mps.ohio-state.edu:/pub/nntplink/3.2pl1.tar.gz.

Ian Phillipps <[e-mail]> notes some criteria for using
nntplink rather than nnptsend:

> (1) If you have more than one backbone feed, you can save a lot of
> bandwidth, without risk, if you use nntplink (less duplication of
> articles over nearly-parallel paths).

> (2) More important, if you have a large number of feeds, nntplink
> permits them to be fed simultaneously with the same articles.  No big
> deal, until you think of the what's going on in the pagedaemon and the
> disk cache.

> A "ps uaxr" rarely catches nntplink in the act ("D"), despite my having
> 17 of them last time I counted. Our biggest outgoing newsfeed delivered
> 16398 articles yesterday, using a total of 380 seconds CPU on a Sun
> IPC, and no disk time :-)


------------------------------

Subject:  How do I use newsgate with INN?

You don't.

The version that is available on the net doesn't work with INN
properly.  Rich Salz is preparing a version that will work with INN or C News.
You can get a copy of it in it's current state (which works, but isn't
polished) by sending email to him at [e-mail].  You must
promise not to distribute what he sends you.

Installation instructions (sample /usr/lib/news/newsfeeds and
/etc/aliases entries are provided in the documentation for newsgate.

NB: newsgate includes mail2news and news2mail.


=====================================================================
               OTHER ERROR MESSAGES AND WHAT THEY MEAN
=====================================================================


------------------------------

Subject:  ld.so: Undefined symbol: _dbzwritethrough

> Everything compiles correctly, but when I try to test rc.local I get:
>
> hermes# sh /usr/local/etc/rc.news
> ld.so: Undefined symbol: _dbzwritethrough
>
> What am I doing wrong?

This means that you are using a $INN/lib/dbz.c file that hasn't been
patched with the $INN/lib/dbz.pch patch.

The patching is automatic.  Running "make" should do the patch without
you even noticing.  To force the code to be re-patched (i.e. copy the
original to dbz.c and apply the patch to it), simply delete
$INN/lib/dbz.c and run the usual "make".  The Makefile does everything
for you.

Why might the patch fail and leave you with an unpatched dbz.c?

1)  You don't have Larry Wall's (or the FSF's) "patch" program
installed.  It is available at ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz

2)  Most C++ compilers based on USL's cfront come with a program called
"patch" that does something completely different than Larry Wall's (or
the FSF's) "patch" program.  If your path is configured so that this
program is found before Larry Wall's (or the FSF's) "patch" program,
you will get an unpatched dbz.c.  To fix this, delete $INN/lib/dbz.c,
change your path, and do the usual "make".  If this file is deleted the
Makefile will do everything for you.

See also section "5.2 The DBZ package" of the Install.ms document.


------------------------------

Subject: Bad file number writing history file -- throttling

The system ulimit was set restrict files from growing beyond a certain
size and the history file was to large for the limit. Check the ulimit
setting for the news user.

The ulimit should be set to infinite.  You need to figure out how to
set this for user "news" no matter if the user logged in, is running
from cron, or was run at boot up.


------------------------------

Subject: log file fills with "<site> <article-id> 436 No space"

innd issues this message if it cannot create a directory for a group,
_no matter what the reason for the failure_.  In most cases,
/usr/spool/news (and the mount point it is symlinked to, if any)
accidentally has permissions and ownerships that do not permit write
access by innd (which runs as "news").  After chowning them to news,
and setting the permissions to 755, everything should work fine.


------------------------------

Subject:  Why does my innd often die with the message "Can't sync history,
        interrupted system call"

Are you running SunOS?  See "Known Problems" section of the
installation manual."  To the best of my knowledge, nobody has seen
this problem on any other system.


------------------------------

Subject:  syslog message: ME cant sendto CCreader bytes 4 No such file or directory

(Rich Salz replies:) It usually means that some ctlinnd command timed
out and gave up before innd could get around to replying.  Always a
problem with datagrams.  :-)  Usually not a problem in real life
however.  In INN1.3, the timeout stuff is handled better so most of
these should go away.

You can ignore the messages, but if it bothers you, edit news.daily and
find this line:

    ctlinnd -s -t`wc -l <${ACTIVE}` renumber '' 2>&1
You can rewrite it to be something like this:
    COUNT=`wc -l <${ACTIVE}`
    ctlinnd -s -t`expr ${COUNT} \* 5` renumber '' 2>&1


------------------------------

Subject:  syslog: cant symlink

This usually means an intermediate directory doesn't exist.  Usually
"ctlinnd renumber" clears this problem, but doesn't remove the cause.

This is usually an indication of some larger problem.  Often it means
that you have opted to use MMAP on an operating system (like Ultrix)
that doesn't have a working mmap() function.  However, this would only
be the cause if you ignored the Install.ms *and* part 1 of this FAQ.
So, obviously, this isn't the cause :-).


------------------------------

Subject:  syslog: cant read Connection reset by peer

This means that the client vanished or deliberately aborted the nnrpd
TCP stream rather than closing it gracefully.  This is a common
situation, and it does not normally indicate a problem.

Most, or all, of these messages are due to clients crashing or being
aborted in the middle of a dialogue with nnrpd.  For example, a PC or
Mac user shuts off their machine at 5pm.  Or, you are seeing the
results of a bad design decision in the NewsWatcher newsreading program
for the Mac.  Future versions of NewsWatcher will be (hopefully) more
graceful about closing connections.  In other words, they should
send "QUIT\r\n" on the socket, then close it.


------------------------------

Subject:  inews says "bad message-id"

If this is a Solaris 2.x system, you didn't delete the lines mentioned
in "SVR4, Solaris 2.x, and SCO ODT 3.0" in part 1 of this FAQ.


------------------------------

Subject:  Why do all these "readclose" messages show up in my syslog?

Chris Schmidt <[e-mail]> says:

The "readclose" message indicates that a remote connection to your
server was not correctly terminated with the server-command "quit".
This can have two reasons.  First the line your feed uses to connect to
you might be instable so that the connection drops every now and then.
Solution:  either ignore theses messages or find out why the line is
unstable.  The second reason for these messages could be a
missconfigured client-program at your feed.  This means the program
(e.g nntplink) does close the connection without sending the "quit"
first.  If you configure a lower number for the exit-timeout (-e) than
the close-timeout (-C) in nntplink then exactly this will happen.
Solution:  ask your feed to fix its nntplink-setup.  Let me repeat
that:  If you are using "nntplink" your -e value must be higher than
your -C value.


------------------------------

Subject:  "File exists writing symlinking article file -- throttling"

QUESTION: I'm running INN 1.4, and the server throttles itself, saying
"File exists writing symlinking article file -- throttling".  Why?  I
have no clue, other than to note that the message is being emitted
while innd/art.c tries to link a crossposted group.

ANSWER:  Innd wrote the article to comp/foo/123 and then tried to
symlink it to alt/bar/128 and found that the symlink failed with errno
== EEXIST.  This generally only happens when your active file does not
match your file/directory use.  The three most common cases of that are:

        Trying to use MMAP on Ultrix
        Trying to use MMAP on Linux
        Some strange interaction with tind.

If you are using Ultrix or Linux, turn off MMAP.  You don't have a choice in
this.  The Ultrix mmap() function does something completely different
than the Sun/BSD mmap() function.  The Linux function gives you some
of the functionality that Sun/BSD mmap() function has, but not enough.
(The Linux people expect to have it fully up to spec eventually, yeah right.)

At least one person has reported problems with ICL DRS6000 SVR4 Unix
when using MMAP.  Try turning off MMAP if you find problems.

It has been reported that tind writes to the active file and this
confuses innd (innd assumes it is the only process writing to the
active file).  If you are using tin, upgrade to the newest version of
tin, it can read the NOV database rather than the "tin" database.

To fix the active file (which may be corrupted), make sure nobody
else is writing to the active file, then do
        ctlinnd renumber ''
to get things synchronized again.

If your history file is corrupt, you should do:
        ctlinnd renumber ''
        makehistory -buv
        ctlinnd renumber ''
(Note: the "makehistory" will take hours to run.)

IF YOU IGNORE THIS PROBLEM LONG ENOUGH (by issuing the "go" command via
ctlinnd) you will eventually get a "innd: ME cant update_active
control" message in syslog.  The cause of this error is dealt with
elsewhere in this FAQ.


------------------------------

Subject:  "cant fopen <newsgroup>/.thread No such file or directory"

Q: nnrpd logs "cant fopen <newsgroup>/.thread No such file or
   directory" hundreds of times a day although I installed trn-3 and
   maintain an overview database.  Why doesn't trn use overview files
   instead of mthreads data?

A: trn-3 tries to open .thread files (or use XTHREAD) first because
   $spooldir/db.init still exists.  Delete it.


------------------------------

Subject:  news.daily reports: "Expire had problems removing articles"

This message tells you that you need to look in the file
${MOST_LOGS}/expire.log to find out what really happened.

On the other hand...

Expire reports this if it goes through the entire expire process and
didn't find any articles to remove.  It is normal to get this error the
first few days you are running INN.  For example, if the smallest
integer that appears in the 4th field of your expire.ctl is a "4", then
you're sure to see this error the first four days you get an news.daily
report.

However, those first four days are when you are still learning the
system and it can be very shocking to see the error.  "Eeek!  Did I do
something wrong?"  Nope, news.daily is just telling you that you have a
virginal system.

Rich writes a more technical explanation:
> When using the "delayrm" keyword, news.daily calls expirerm to
> actually remove the articles that expire listed in its "-z" file.
> As distributed, expirerm calls fastrm with the "-e" flag.  This
> flag says "exit non-zero if nothing was removed."  In the normal
> case, it is an error if expire doesn't find anything to remove.

...and a system being 4 days old isn't the normal case.  So you
get the error.  Ignore it.


------------------------------

Subject:  syslog: nnrpd[22560]: ? cant gethostbyaddr 198.3.24.3 Permission denied

When someone connects to nnrpd, nnrpd does a reverse lookup on the
clients IP address so it can look up the hostname in nnrpd.access.  If
the client's DNS information is incorrect, you will get this error.
Make sure your SOA record is correct, as well as your in-addr.arpa
data.

Derek <[e-mail]> adds that another cause for this problem,
at least under SunOS 4.1.x, is that nnrpd wasn't linked with the proper
resolver library (statically or dynamically).  Even when you've
replaced Sun's fershlugger libresolv.a you've still gotta remind
yourself to _use_ it properly.


------------------------------

Subject:  syslog: ME cant nonblock 15 Operation not supported.

I get the following "syslog" message in /var/adm/messages:

Dec  2 20:40:04 venus innd: ME cant nonblock 15 Operation not supported

Answer: (from [e-mail] (Paul Riddle))

It turns out that this is happening because /usr/spool/news on the
machine running innd is an NFS-mounted filesystem, and innd is trying
to do an FIONBIO on my feed file, which is under /usr/spool/news/out.going.

([e-mail] adds:)
All news transports (INN, C news, B news) want the spool partition to
be local.  Newsreader can read from an NFS mounted partition without
any problems but innd should only see local partitions.  NFS has a
blatant disregard for many of the file semantics that are needed for a
good netnews implementation.  If you don't agree, please feel free to
prove the authors of B news, C news, and INN wrong.  Include source
code. :-)

Systems without unix-domain sockets sometimes see this error.  Just
ignore it.


------------------------------

Subject:  innd: ME cant update_active control

What does "innd: ME cant update_active control" mean?

Look at your active file.  One of the fields is "99999" and has to be
incremented to "100000" but there is no space.  Shut down innd
("ctlinnd shutdown x").  Edit your active file (see the "Safe way to
edit the "active" file?" question in INN FAQ part 3) to add more
leading zero's to all the numbers.  Restart innd.


------------------------------

Subject:  syslog message: innxmit[1234]: max connect failed Error 0

John Line <[e-mail]> writes:

If you get syslog messages like "innxmit[1234]: max connect failed
Error 0" when using nntpsend, it probably means you messed up a line in
nntpsend.ctl (specifically, missed out one of the first two fields).
While nntpsend.ctl is an obvious place to look for an nntpsend problem,
there is nothing obvious to link the error message directly to the
problem, because the text "max" is actually something invented by
nntpsend when processing the file, and doesn't exist in nntpsend.ctl.
It means the next-to-last field was null, but was the second field when
it should have been the third!

NB Remember to try inncheck when you have problems like this. I only
just thought of it, after finding the problem the hard way, and it
immediately reported "nntpsend.ctl:18: malformed line."


------------------------------

Subject:  Can't open "/usr/local/news/shlock955", Permission denied

This usually means you don't have /usr/local/news owned by "news".  The
first time you run "make install" it should set the proper ownership if
you run "make install" as "root".


------------------------------

Subject:  INND: PID file exists -- unclean shutdown!

This just means your machine crashed or you didn't shutdown innd
properly and THEREFORE rc.news is doing a bit of cleanup work before it
starts innd.

There is nothing for you to do.


------------------------------

Subject:  cant fopen /usr/lib/news/distributions

Step 1:  Can you "cat" this file?

Step 2:  You can't?  Does it exist?

Step 3:  It doesn't?  That's because you have to create it yourself.
It should list every distribution your users might want to know a
discription of, starting with the local one.

Step 4:  Here's a sample file to start from.  It's appropriate for
a New Jersey site:

nj    New Jersey
ny    New York
nyc    New York City
ne    North East, USA
usa    United States of America
na    North America


------------------------------

Subject:  cant fopen /usr/lib/news/distrib.pats

A sample distrib.pats comes with the distribution and should
be in your $inn/site directory automatically.  The sample
file can be used without modification.  If you get this
error it sounds like something was badly configured on your
machine.


------------------------------

Subject:  ME cant exec in /usr/lib/news/capture No such file or directory

The newsfeeds file includes lines that looks like this:

## Capture all Foo, Incorporated, postings
#capture\
#       :*/foo\
#       :Tp,H2:/usr/lib/news/capture %s

That's just a sample of how one might capture articles.  There is no
capture program that comes with INN.  It's just an example of how to
use the Tp,H2 flags.

Don't uncomment anything that you don't want to activate!


--
 George Will, Rush Limbaugh, John Sununu, Pat Buchanan, James Kilpatrick, Mona
  Charen, G. Gordon Liddy, Robert Novak, Bay Buchanan, Pat Robertson, Joseph
   Sobran, Paul Harvey, Phyllis Schafly, Maureen Reagan, and John McLaughlin
          always bemoan the need for more conservative media voices.
Posted-By: post_faq 2.10
Archive-name: usenet/software/inn-faq/part3
Last Changed: $Id: FAQ-inn.3,v 1.111 1995/02/27 09:14:01 tal Exp $

                  Part 3 of 4

INN FAQ Part 1/4: General Information
INN FAQ Part 2/4: Debugging Guide & Tutorial
INN FAQ Part 3/4: Operational and Misc. Questions
                    Day-to-day operational questions
                    INN is running, but i have this small problem...
                    How do i... (Big changes you can make to the system)
                    Bugs in INN 1.5:
                    Bugs in INN 1.4:
                    Bugs in INN 1.3:
                    Bugs in INN 1.2:
INN FAQ Part 4/4: Appendix A: Norman's install guide


------------------------------

Subject:  Table Of Contents for Part 3/4

=====================================================================
  TABLE OF CONTENTS FOR PART 3/4:  Operational and Misc. Questions
=====================================================================

DAY-TO-DAY OPERATIONAL QUESTIONS:
    How do I create all those directories in the newsspool?
    Why is /usr/lib/news/newsgroups not found?
    Safe way to edit the "active" file?
    What's the best way to upgrade to a new version of INN?
    How do I talk to innd from C or Perl?
    After a crash.
    How do I moderate a mailing list?
    How do I configure the /usr/lib/news/moderators file?
    Listing every article
INN IS RUNNING, BUT I HAVE THIS SMALL PROBLEM...:
    XHDR says Bad Article Number
    Everything I receive, I re-feed to the feeder
    Suddenly my active and history files are owned by root!
    How come my host name comes out twice in the Path line?
    Expire had problems last night, and while I fixed the problem,
    expire reports "Group not matched (removed?) --
        Using default expiration"
    Why doesn't this newsfeeds entry do what I want?
    Why am I forwarding cancel messages for articles in comp.foo
    Debugging someone that is feeding you.
    Feeds suddenly can't connect anymore!
    I'm getting groups sent to me that I don't want.
    When my feeder connects, I get articles but they don't take
        what's waiting for them.
    Directories are being created with wrong permissions.
    Why am I getting alt.sex.pictures even though I have...
    More about the "to.*" groups
    What's a decent syslog.conf configuration?
    INN batcher writing "#!rnews 0" separators
    Posting while throttled doesn't work
    overchan can't keep up.
    "newgroup" control messages aren't being executed
HOW DO I... (Big changes you can make to the system):
    How do I set up a delayed IHAVE/SENDME over NNTP?
    Can I use gzip with INN?
    What do I do if /var/spool/news is split over multiple partitions?
    Archiving expired articles
    How do I restrict access on certain newsgroups (like alt.sex)
    INN on one machine, UUCP modem on a different one
    Setting up proxy-nntp to talk through a firewall
    How do I set up inpaths with INN?
BUGS IN 1.4:
    Security Patch
    Looping Select Patch
BUGS IN 1.3:
    7-bit encoded batches are not correctly processed. Why is this?
    NOV (overchan) doesn't work well.
BUGS IN 1.2:
    Why doesn't nntpget work?


=====================================================================
                  DAY-TO-DAY OPERATIONAL QUESTIONS
=====================================================================


------------------------------

Subject:  How do I create all those directories in the newsspool?

Q:  For example, if you receive comp.sys.amiga.applications, do you
have to mkdir /var/spool/news/comp/sys/amiga/applications?

A:  Nope.  innd creates the directory for you the first time you
receive an article for that newsgroup.


------------------------------

Subject:  Why is /usr/lib/news/newsgroups not found?

The latest rev is in:
        ftp://ftp.uu.net/networking/news/config/newsgroups.Z
Get it and install it.

------------------------------

Subject:  Safe way to edit the "active" file?

First of all, you could manipulate the active file using the ctlinnd
"newgroup", "rmgroup" and "changegroup" commands.  However, sometimes
you just need to do a lot of editing all at once:

The following sequence is the shortest:

    ctlinnd pause "edit active"
    [do something to the active file]
    ctlinnd reload active "edit active"
    ctlinnd go "edit active"

Simple!  No need to "flush" since the "pause" does that.

> What if I need to delete 3000 lines from my active file?

I would definately edit the active file manually (using
the above procedure).

> What if I need to delete 10 lines from my active file?

For a couple quick changes, I recommend using "ctlinnd".  This is a
little slow because all channels are closed and reopened after each
"rmgroup", "newgroup", and "changegroup".  However, it's easier than
remembering the above sequence.

DO NOT THROTTLE THE SERVER WHEN DOING MULTIPLE rmgroup COMMANDS.  There
is a bug in INN (all versions) that will shred your active file if you
do multiple "rmgroup" messages while the server if throttled.  This is
a common mistake.  People think the "rmgroup"'s will go faster if the
server is throttled.  It will go faster, it will also shred your active
file.

If you have a large number of groups to remove or create, you can use
awk to write a script to do the work for you.

    % cat thelist
    alt.foo.bar
    alt.delete.me
    comp.sys.mac
    % awk <thelist '{ print "ctlinnd rmgroup " $1 }'
    ctlinnd rmgroup alt.foo.bar
    ctlinnd rmgroup alt.delete.me
    ctlinnd rmgroup comp.sys.mac

Now, you can either send the output of that to "| sh -x",
or you can redirect the output to a file, and "source" the
file.

If you want to create a bunch of newsgroups, the awk
command might be like this:

    % awk <thelist \
    '{ print "ctlinnd newgroup " $1 " y user@host" }' | sh -x


------------------------------

Subject:  What's the best way to upgrade to a new version of INN?

First, you should read the README and the Install.ms (yes, read
them both... again).   Things change in new versions.

Second, the README explains how to do an upgrade.  This document
is redundent, but explains the procedure in more detail.

STEP 1:  Copy the values in the old config.data to your new config.data.
You can do this automaticly with this trick:

    % cd config
    % make subst
    % cp config.dist config.data
    % ./subst -f {OLDFILE} config.data
where "{OLDFILE}" names your old config.data file.

STEP 2:  Edit the config.data to see if you want to change any of
the new settings that didn't exist in the old version's config.data
file.

STEP 3: Compile everything:

    % cd $INN
    % make all
(you can run "make world", which also runs "lint".  If you don't
know what "lint" is, just ignore anything it outputs.  If it bombs,
run "make all" instead.)

STEP 4: When you feel you are ready to install the new files shut down
    the old daemon:

    % ctlinnd shutdown 'upgrade in progress'
    [ kill innwatch by hand if you need to ]

STEP 4: Install the new files:

    % cd $INN
    % make update

STEP 5: Now update all your $INN/site files to be the same as they were
for your old software.  "cd $INN/site ; make diff-installed" will tell
you what's different between the files in /usr/lib/news and $INN/site.
If you only make changes in the $INN/site directory and use "make
install" to copy them into place you'll save your self a lot of
trouble.  Read $INN/site/Makefile for more interesting things that
"make" can do.

STEP 6: When you feel you are ready to install the new $INN/site files:

    # cd $INN/site
    # make install

STEP 7: Re-start the system:

    % sh /usr/lib/news/etc/rc.news

STEP 8: If everything was done right you should be up and running.
Part 2 of the FAQ gives tips on testing your configuration.


------------------------------

Subject:  How do I talk to innd from C or Perl?

Rich Salz says:

If you are writing C, look at doc/inndcomm.3 and include/inndcomm.h;
they include all you need to do any ctlinnd command (in fact, ctlinnd
itself is little more than a call to the library).

Hacking up a Perl subroutine that spoke to innd's Unix-domain control
socket should be fairly straightforward but hasn't yet been written.


------------------------------

Subject:  After a crash.

"What do I do after a system crash?"

INN handles crashes pretty well.  If there are any problems they
get cleaned up by the nightly expire.  About once a month you
might want to run "makehistory -buv" to look for "lost" articles.
Check the man page for "makehistory" for more information.
(The man page for "makehistory" is in the news-recovery man
page until INN 1.4).


------------------------------

Subject: How do I moderate a mailing list?

Ask your news administrator.  If you are the news administrator, read
RFC 1036.  (also, refer to "How do I configure the
/usr/lib/news/moderators file?")


------------------------------

Subject: How do I configure the /usr/lib/news/moderators file?

Q: The 'moderators' file that comes with INN has only the following
lines:

    gnu.*:[e-mail]
    *:[e-mail]

Should this be changed?  That is, if at Usenet site, does the news
admin have to configure this file in order for INN to email the local
posts to moderated newsgroups to the correct moderator?  In this case
then, every time a new moderated group is created, and/or changes its
moderator, it should be necessary to change this file.

A: Fortunately not!

First of all, the default configuration says, "The moderator for
foo.bar is [e-mail]".  The good people at UUNET keep mail
aliases for all the moderated newsgroups so that as moderators come and
go, they will always forward to the correct person.

Refer to the "How to Construct the Mailpaths File" FAQ, for an
explanation of the moderation mechanism.  This article explains the
'mailpaths' file from C News, which is similar in nature to the INN's
'moderators' file although with a different syntax.

The file 'moderators' could be modified, though, according to that
article.  For example, there are other sites that do what UUNET does,
and they might be closer to you.

Also, you might want to take a look to the inn.conf(5) man page to read
the 'moderatormailer' parameter description.


------------------------------

Subject:  Listing every article

People often ask for a way to list every file in the newsspool.  There
are a couple ways of doing this.  They work well for INN as well as C
News:

1. Here's the fastest way.  However, it only lists the files that are
actually in the history file and if an article is crossposted it only
gets listed once:

#!/bin/sh
. /usr/lib/news/innshellvars
cd ${SPOOL}
awk '(NF > 2){print $3}' < ${HISTORY} | tr . /

Sorting the output will improve directory cache efficiency.

2. This lists any article file no matter how many links
you have, etc. and even if it is not listed in the history
file:

    cd /var/spool/news
    gfind . -regex '.*/[0-9][0-9]*$' -print

NOTE: GNU find will execute this much faster than the "find" that
comes with most versions of Unix (including SunOS).

3. If you need to do something fancier than what find can do, consider
using perl's find2perl program.  Given a find command line, find2perl
will output the perl code to do the same thing.  You can then modify
the output to do what you want.  For example:

    find2perl . -mtime +30 -name '[0-9][0-9]*$' -exec '/bin/rm {}'

outputs a perl script that deletes any article that is over 30 days old
(except the regular expression is output as wrong...  change it to:

    /^[0-9]+$/ &&

and it should work just fine.


=====================================================================
          INN IS RUNNING, BUT I HAVE THIS SMALL PROBLEM...
=====================================================================

------------------------------

Subject:  XHDR says Bad Article Number

Q: When I do a XHDR command the INN NNTP server may give
me article numbers which is not valid (get 403 Bad Article Number
when requesting the article text). Is this normal?

A: Absoltuely not!

Perhaps DIR_STYLE is wrong?


------------------------------

Subject:  Everything I receive, I re-feed to the feeder

"It seems that all the articles sent to me are resent back to my
provider.  I only want to post those articles which have been locally
generated at my site back to my news feed provider."

or "I feed a site named foo.bar, but it puts something besides foo.bar
in their Path: header"

Let's look at a typical Path: line:

Path: plts!sdl!newsgw.mentorg.com!uunet!gatech!howland.reston.ans.net!agate!barrnet.net!jfrank.com!usenet

As a post goes from system to system, each site prepends their sitename
to the line.  Usually a site uses their FQDN, but sometimes they register
something with the UUCP Mapping Project which makes sure no two sites use
the same name.  In the above, we see a couple FQDN's and a couple sites
that are registered with the UUCP Mapping Project.

INN will not feed this article to any feed who's name appears in the Path:
header.

Suppose you have a feed to/from barrnet.net that looks like this:

netnews.barrnet.net:*,!control,!junk:Tf,Wnm:

This means "send all newsgroups except control and junk, but not if the
Path: line includes 'netnews.barrnet.net'".  That's fine, but as we see
in the above Path: example, BarrNet puts "barrnet.net" in the path,
even though their netnews machine is called "netnews.barrnet.net".

Therefore, we change the newsfeeds file to include a "/barrnet.net"
which means "exclude posts that have gone through barrnet.net".

netnews.barrnet.net/barrnet.net:*,!control,!junk:Tf,Wnm:

Now you won't feed to netnews.barrnet.net articles that have already
gone through barrnet.

The best way to solve this problem is:
    1.  Read the Path: line from an article that has passed
        through that site already.
    2.  Insert that sitename into the feeds description in newsfeeds.
    3.  "ctlinnd reload newsfeeds fixed_feed"

OTHER USES:

Suppose two sites have very reliable NNTP feeds from uunet and psinet
but still want a feed between each other to increase redundency.  They
might set up feeds like:

othersite/uunet,uupsi:...

so that they aren't sending articles that have already reached two of
the biggest sites on Usenet (and therefore must have gotten good
distribution already), but will pass on everything else.


------------------------------

Subject:  Suddenly my active and history files are owned by root!

rc.news runs from root.  After that, everything else should run as
news.  It sounds like you've run news.daily as root by mistake.  Make
sure all your cron jobs run as news and you'll be fine.

If you have an old "cron" system, you might consider replacing yours
with one of the many public domain replacements.  If you can't create
a different "crontab" for each user, the idiom is:

0 * * * * * su news -c '/do/this/as/news'


------------------------------

Subject:  How come my host name comes out twice in the Path line?

The INN server puts its name in the Path line of every article that it
receives.  Obviously, it has to do this.  The default configuration has
inews put the local host in the Path header.  If nobody posts on the
server and you use fully-qualified domain names on your workstations,
then everything works the right way.  (If `hostname` doesn't give an
FQDN on your machine, you can work-around this by setting the "domain"
value in inn.conf; remember that innd never re-reads inn.conf.  You
must "ctlinnd shutdown x" and then re-start the server).  Many people
don't want the client machines to put their name in the Path header.
To do this, set INEWS_PATH to DONT.  Finally, let me say that it is
probably a mistake to have a "pathhost" line on any machine other than
your server if you set INEWS_PATH to DO.  If you doubt this, please
trace the article flow for yourself.  If you are curious about the
effect of INEWS_PATH, read the nroff source -- not the formatted
output -- of doc/inews.1


------------------------------

Subject:  Expire had problems last night, and while I fixed the
            problem, it still won't run.

When expire starts up it "reserves" the server so that nobody else can
pause or throttle it.  This prevents anyone else from coming in and
modifying the history database.  If expire bails out because of a bad
error (e.g., your expire.ctl has syntax errors) it leaves the server
reserved so that no maintenance will be done until a good expire run has
occurred.  To unblock the server, use the ctlinnd "reserve" command with
an empty string argument.


------------------------------

Subject: expire reports "Group not matched (removed?) --
        Using default expiration"

Expire says:
Group not matched (removed?) alt.techno-shamanism -- Using default expiration
Group not matched (removed?) misc.computers.forsale -- Using default expiration
Group not matched (removed?) de.rec.sf.startrek -- Using default expiration

YOU DID NOTHING WRONG!

That just means that you've removed those newsgroups groups and expire
is slowly removing articles from the spool as they expire.  Eventually
the articles will all have been deleted and so will these messages.

Here's a neat trick to make deleted groups go away at the next expire
instead of hanging around waiting for their articles to expire in a
timely manner.  Using this combination of lines at the *start* of
expire.ctl:
    *:A:0:0:0
    *:U:0:7:31
    *:M:0:14:365
will cause groups which are neither moderated nor unmoderated to be
discarded - the only such groups are deleted ones.  Thanks to
[e-mail] (Ian Phillipps) for this tip!


------------------------------

Subject:  Why doesn't this newsfeeds entry do what I want?
            "foo.com:alt,!alt.sex"

A newsfeeds entry is not a sys file (C News) entry.  Please read
newsfeeds.5.  You might also find the sys2nf program in the frontends
directory useful, as well as the inncheck Perl script that is found in
the samples directory.  The INN Configuration FAQ has cook-book
examples of the steps required to install a NNTP feed, UUCP feed, and
NNTP via nntplink feed.


------------------------------

Subject:  Why am I forwarding cancel messages for articles in comp.foo
            when I explicitly have !comp.foo in the newsfeeds entry?

Control messages can be explicitly forwarded, so a control message to
comp.foo is forwarded to sites that recieve either comp.foo or control.
Please see the "Control Messages" section of innd.8.  As that
documentation says, you probably want to put "!control" in the
subscription list for most of your newsfeeds.


------------------------------

Subject:  Debugging someone that is feeding you.

David Myers <[e-mail]> suggests that if a neighbor complains
that their feed to you doesn't work: (1) make sure they've read the man
pages, and (2) have them send a copy of their newsfeeds file.

Truly sage advice!


------------------------------

Subject:  Feeds suddenly can't connect anymore!

Q:  How come feeds tell me they can't connect to me any more?

A:  When innd starts up it reads the hosts.nntp file and looks up the
IP addresses for all the entries mentioned there.  The problem is that
this data is dynamic (sometimes people change IP addresses), and innd
never goes back to check.  If your system stays up for days and one of
your feeds changes their IP address (or has a new CNAME), innd will
reject them.  Rich plans to handle this in INN1.5, but for now you
might find it useful to do a "ctlinnd reload hosts.nntp" out of cron
every day or so or when you notice there's a problem.

Here is a sample crontab entry to use: (news should run this)

55 7,12,17,22 * * * /usr/local/newsbin/ctlinnd -s reload hosts.nntp crontab

I hope people vary the time this runs.  If a huge number of INN hosts,
many running NTP so their clocks are within a few ms., all kick off DNS
lookups at exactly the same time, the internet traffic could get
"interesting".  Try setting the minutes value to the time you added
this entry to crontab rather than everyone using "55".  In fact, if
everyone used their birthday plus 1 if they are born on an odd month,
that would spread it out just fine.


------------------------------

Subject:  I'm getting groups sent to me that I don't want.

Tell the system administrator(s) of the machine(s) that feed news to
you to stop sending those groups.  There is no other way to do it.  (In
B or C News, the groups would end up in junk; at least with INN they
are not taking up space.  You should compile with WANT_JUNK set to
DONT).

If the people that feed you use B news or C news, remember that they
don't use a "newsfeeds" file.  They use a file called "sys" which has a
completely different format for specifying newsgroups.


------------------------------

Subject:  When my feeder connects, I get articles but they don't take what's waiting for them.

I hate to say this, but this really shows that you haven't RTFMed very
much.

News is not automaticly bidirectional (it's like SMTP, not UUCP).  If
you want to send things out you will have to make sure that you run
send-nntp or nntpsend from cron.  nntpsend is easier and elsewhere in
this document there are cookbook examples of what to add every time you
set up a new feed.


------------------------------

Subject:  Directories are being created with wrong permissions.

> Question:
>When I received news for /var/spool/news/foo/bar for the first
>time, the directories got created:
>
># ls -lgR foo
>total 1
>d-wx-w-rwx  2 news     news          512 Feb  9 00:03 bar/
>
>What did I do wrong?
>
>##  Mode that directories are created under.
>#### =()<GROUPDIR_MODE          @<GROUPDIR_MODE>@>()=
>GROUPDIR_MODE           2775

  Answer:
You forgot a zero in front of this number, for the C compiler to interpret it
as octal instead of decimal.


------------------------------

Subject:  Why am I getting alt.sex.pictures even though I have
            "ME:!alt.sex.pictures" in my newsfeeds file?

The active file is the definitive list of what newsgroups you receive.
INN's ME entry is different from C News and B News; please see
newsfeeds.5.  If you do not want to receive alt.sex.pictures, ask the
system(s) that send you news not to send it to you.  (You would have to do
that no matter what news system you are running.)


------------------------------

Subject:  More about the "to.*" groups

(Thanks to [e-mail] (Joseph Malcolm) for supplying
these answers.)

>1) Why did my local INN act on the sendsys posted to to.neighbor?

to.* groups aren't magic to INN.  Your system received the message,
it acted on it.

>2) Why did my neighbor send the cmsg to all of his neighbors?

See 3.

>3) Is is related to having the "control" group in our newsgroups patterns?

Yes.

>   The INN docs say you probably don't want to do this, but they don't say
>   why.

Actually, they do. This is from innd(8):

    Sites may explicitly have the ``control'' newsgroup in their
    subscription  list,  although  it is usually best to exclude
    it.  If a control message is posted to a  group  whose  name
    ends  with  the  four characters ``.ctl'' then the suffix is
    stripped off and what is left is used  as  the  group  name.
    For  example,  a cancel message posted to ``news.admin.misc.ctl''
    will be sent to all sites that subscribe to  ``control''  or
    ``news.admin.misc''.

There is also a pointer to this in newsfeeds(5).

>   But I still need it in my active file, right?

Yes.


------------------------------

Subject:  What's a decent syslog.conf configuration?

The configuration will be different for each site, but here is what
Greg Earle recommends as the lines for the "news.*" related part.
Remember that most syslog's require tabs, not spaces.

Greg's canonical SunOS 4.1.x INN-related syslog.conf entries (which can
be merged into your current configuration):

#
# INN stuff
#
##  Send critical messages to everyone who is logged in and to the console.
news.crit               *
news.crit               /dev/console

##  Log news messages to separate files.
##  Note that each level includes all of the above it.
## =()<news.crit        @<_PATH_MOST_LOGS>@/news.crit>()=
news.crit               /var/log/news/news.crit
## =()<news.err         @<_PATH_MOST_LOGS>@/news.err>()=
news.err                /var/log/news/news.err
## =()<news.notice      @<_PATH_MOST_LOGS>@/news.notice>()=
news.notice             /var/log/news/news.notice


------------------------------

Subject:  INN batcher writing "#!rnews 0" separators

>Outgoing UUCP batches from here are going out with "#!rnews 0" at
>the head of each article.

Most common cause:  your newsfeeds entry has "Wnm" not "Wnb".

Other reasons:

batchfiles have something other than a single space between article
filename and size

batchfiles lack size information (all the articles sizes will be read
from the batch file as zero)


------------------------------

Subject:  Posting while throttled doesn't work

>I want to be able to allow my users to be able to post articles when
>innwatch has throttled the system when the spool disk is "full".

Cannot be done in 1.4.

At a minimum, in 1.5 nnrpd will spool the post for the user.


------------------------------

Subject:  overchan can't keep up.

> About once a month or so, I get the following warning messages:
>
> Jan 20 07:20:22 optima innd: overview!:31:proc:9193 cant flush count 14639 Operation would block
> Jan 20 07:20:22 optima innd: overview! spooling 14639 bytes

or

> there's a file "overview!" in /usr/spool/news/out.going with stuff in it.
>
> Should I be doing anything more with this than ignoring it, and maybe
> occasionally deleting it (it just grows)?

This happens because innd is feeding info to overchan faster than
overchan can process it.  The overflow is sent to the file
"overview!".  This file can be deleted, as nnrpd will grab the missing
data out of the articles "manually".  The slow-down won't be noticed,
much.  You can "expireover -a" to "fill in the holes".

To prevent this in the future, you need to make overchan run faster.
This is easy to do.  There are two things to do:

1.  Increase the size of many of your kernel buffers.  In particular,
increase buffers relating to directory caches (the "namei" cache", to
mention one).  If you use SunOS, change "maxusers" to 200.  Ignore the
variable's name.  This variable is used to calculate most of the other
buffer sizes, etc. and 200 is good for a system that is as overworked
as, say, a machine running netnews.

2.  (this is more important than #1) Move the .overview files out of
the /var/spool/news hierarchy.  For example, moving the overview files
into /var/spool/news/over.view made things fast enough on one machine
that the problem went away.  To do this:  change "_PATH_OVERVIEWDIR" in
"config.data", recompile, and "make install".  You will need to
recompile any newsreaders that read via NFS or off the local disk.

For really great performance, put the NOV files on a separate disk.
(Not just a separate partition, a separate disk or spindle.)

This one-liner will generate a shell script that will move your NOV files:
    awk '{ print $1 }' /usr/lib/news/active | tr . / | awk '{ print "mkdir -p /new/location/" $1 ; print "mv " $1 "/.overview /new/location/" $1 "/.overview" }'

WHY THIS WORKS:

Why does doing all this speed up overchan?  overchan works by opening
the proper ".overview" file, appending 1 line to it, then closing the
file.  If you have the ".overview" file in the same directory as 10000
articles then opening the ".overview" file will take a huge amount of
time.  The open() call literally searches though about 5000 (half of
10000) file names to find ".overview".  If you move your ".overview"
files so that each one is in it's own directory, (say,
/usr/spool/news/over.view/{group}/{name}/.overview) then open() is
searching through 3 files ( ".", "..", and ".overview") to find 1
file.  ( O(N/2) where N=10000 vs. N=3... and you thought those first
year CS classes would never be useful!)

There isn't much you can do to make the "append" and "close" steps much
faster, except maybe install a PrestoServe or similar write-cache, and
that won't help very much.

Profiling overchan (with PureSoft's Quantify product) found that the
open() call was around 80% of the execution time of overchan.  That was
reduced to 40% when I moved the ".overview" files to their own
directory.  With the change, overview's profiling statistics are pretty
flat. (which is good).

IF YOU CAN'T DO THE ABOVE CHANGES:
Run "expireover -a" to fix the problem temporarily.  However, it will
come back.

DO NOT try feeding the "overview!" file to overchan manually.
    (1) overchan doesn't do any locking and you'll have two overchan's
        running at once.
    (2) overchan only appends to the ".overview" files.  If you've gotten
        any articles since the "overview!" file was created (you will
        have) then you'll be appending told old entries that are out of
        order.  Your ".overview" files must be in sorted order for the
        other utilities to work right.


------------------------------

Subject:  "newgroup" control messages aren't being executed

> "newgroup" control messages aren't be executed

The usual blame for this is _PATH_EGREP points to a grep that doesn't
understand regular expressions.  For example, GNU grep only understands
regular expressions if it is called "egrep" (i.e. not "gnuegrep" or
"egnugrep").

Make sure you have a link or symlink between egnugrep and egrep.  You
then need to modify config.data so that _PATH_EGREP is
/your/local/path/egrep and NOT /your/local/path/egnuegrep.  Then
recompile and "make install" to have the new binaries and shell
scripts installed.

You also want to check the syntax of your control.ctl file.


=====================================================================
        HOW DO I... (Big changes you can make to the system)
=====================================================================

------------------------------

Subject:  How do I set up a delayed IHAVE/SENDME over NNTP?

Christophe Wolfhugel <[e-mail]> writes:

Having some of your NNTP newsfeeds delayed by a fixed amount of time is
a good way to reduce your bandwith requirements, or a good way to set
up a backup-feed.  By including a Wt flag in your newsfeeds file, INN
will insert timestamp entries in that batchfile, channels, or
exploders.  This timestamp can be used to implement delayed
ihave/sendme processing.  INN's senders (like innxmit) do not use that
data yet.  However, NNTPLINK does support this delayed IHAVE/SENDME
mechanism since release 3.3  (NNTPLINK can be found on
shape.mps.ohio-state.edu:/pub/nntplink/nntplink.tar.gz).

HOW TO DO IT:

The syntax that you would use in your newsfeeds file would be:

    site:*:Tf,Wtmn:

and run this command now and then:

    nntplink -i batchfile -y 300 -b site news.site.fr

The delayed IHAVE/SENDME is expected to allow bandwidth savings in
situations where all sites use nntplink in following topology:

    Your site -- 64k -----------+-----------  Site 1
                                |               |
                                |              2mb
                                |               |
                                +------------ Site 2

   Site 1 and 2 are in the same metropolitan area, you feed them both.
   With the standard nntplink layout, you generally send all articles
   twice, which is a waste even if you're at 2 Meg/s link and even if
   Site 1 and 2 do nntplinks, you're faster.

   The delayed link would be used between your site and Site 2.  A 2 or
   3 minute delay allows Site 1 to feed Site 2 before you, and in case
   of a Site 1 outage the backup starts nearly immediately.

   Reasonnable delays are still kept as You -> 1 -> 2 should take less
   than one minute (or just 300 ms disk to disk if using nntplink -i ? :)).

Experiences seem to show that a 2 to 3 minutes delay is
a reasonable choice.

Chris

------------------------------

Subject:  Can I use gzip with INN?

[this was written with the help of Michael Brouwer
<[e-mail]>]

There are three things that can be effected by using gzip:  Compression
of old logs, compressing batches to send out, and decompressing batches
that come in.

With INN 1.4 all you need to do is change two lines in config.data to
something like this:

COMPRESS                /usr/local/bin/gzip
DOTZ                    .gz

If you rebuild INN with these options set, all logs will be gzipped, and rnews
will use gzip to decompress news.

gzip will automaticly and transparently decompress UNIX Compress, SCO
UNIX Compress (I'm told it's 99% compatible with UNIX Compress), Pack,
and gzip.  Therefore, you can now receive batches compressed with any
of the above listed formats.  Let's say your site is now has "a
universal decompresser".

It has been reported that if you hardlink gzip to be zcat, and make
sure that it is the zcat that INN uses, you can get the "universal
decompresser" without having to use gzip for your logs.  (Though, gzip
for your logs is a big win, so why make trouble for yourself?)

`send-uucp' will still use compress for outgoing batches, so the sites
you feed won't suddenly start getting data they don't understand.

Before you can send gzipped batches, you should make sure that the
sites that you feed have made the above changes so that they have the
"universal decompresser" too.

Edit send-uucp to use gzip instead of compress for certain hosts (see
example of using compress -b12 for the host esac in send-uucp),
outgoing batches will be gzipped.

If you use sendbatch, you will have to edit the file so that COMPRESS
is set to "gzip" and COMPFLAGS is set to "-9vc".


------------------------------

Subject:  What do I do if /var/spool/news is split over multiple partitions?

READ THIS ENTIRE SECTION BEFORE YOU BEGIN.

First of all, you can do this by either mounting a filesystem at
/var/spool/news/comp (for example) or by mounting a filesystem anywhere
and making /var/spool/news/comp a symbolic link to the new partition.

Articles will be written as normal, but cross-posts have to be handled
specially now.  Usually INN handles crossposts by writing the article
to the first newssgroup, and then creating hard links to all the other
places where the article should appear.  Hard links do not take up
additional disk space (except making your directories longer).  Hard
links also have the advantage that the file data doesn't get deleted
until the last hard link is gone (and they can be deleted in any
order).  Therefore, you can expire each newsgroup at a different rate,
but the file data won't delete until it is expired from the last
newsgroup.

The problem is that two hard linked files must both be on the same
filesystem (partition).

When INN sees that it can not make a hard link (because an article is
cross-posted across two partitions) it will try to make a symbolic
link.  If your system can not do symbolic links, set HAVE_SYMLINKS to
DONT in your config.data file.  This will make INN write a second
(or third, etc.) copy of the file instead.  (NOTE: INN 1.4 doesn't
make the extra files.  This feature is planned for INN 1.5.)

Anyway, even though INN will automatically create symbolic links, you
have to give expire the "-l" flag so that it will know to modify its
behavior.  Suppose that a message is posted to rec.photo and
alt.cameras and suppose that rec.photo expires more quickly then the
alt group.  If this happens, then you will be left with a dangling
symlink.  The -l flag prevents this from happening by not removing
the file from rec.photos until alt.cameras expire time permits it
from being deleted.

To inform expire that your spool is split across multiple partitions:

In news.daily, change:
    EXPIREFLAGS="-v1"
to read
    EXPIREFLAGS="-v1 -l"

In expirerm, change:
    RMPROC="fastrm -e -u -s ${SPOOL}"
to read
    RMPROC="fastrm -e -s ${SPOOL}"

Now edit innwatch.ctl so that it checks all the spool disks, not just
".".  See the lines with "No space (spool)".

Lastly, edit innstat (the line with the "df") so that all spool disks
are included.  After that, you're done!

If you ever need to run "makehistory" you should pay attention to the
caveat in makehistory(8) (NB: This man page is called "news-recovery"
in releases before INN 1.5):

MOVING THE FILES:

Here is an example of moving /var/spool/news/rec to its own
partition:
    (mount the new disk onto /mnt)
    cd /var/spool/news/rec
    tar cf - . | ( cd /mnt && tar xpvf )
    If you are confident you did it right, "rm -rf /var/spool/news/rec"
    then "mkdir /var/spool/news/rec".
    umount /mnt
    mount /var/spool/news/rec

If you are moving >50% of the spool, you might use dump instead of tar:
    dump 0f - /var/spool/news | ( cd /mnt && restore xf - rec)

Remember:  If you screw up the /etc/fstab, SunOS and many other UNIXs
won't boot.  fstab can't have any blank lines in many UNIXs either.
Double check the file after you modify it.


------------------------------

Subject:  Archiving expired articles

In <2hmomh$[e-mail]> [e-mail] writes:
>What options do I have in INN for archiving local newsgroups?
>Any help would be appreciated. Any cookbook examples would also help.

See doc/archive.8.  You could also put "never:never:never" in your
expire.ctl file.

Here's a cookbook example of an archive feed:
    # Feed all moderated source postings to an archiver
    source-archive!:!*,*sources*,!*wanted*,!*.d\
        :Tc,Nm,Wn:/usr/local/bin/archive -f -i /usr/spool/news.archive/INDEX

Ulf Kieber <[e-mail]> writes:
The INN 1.4 newsfeeds(5) man page show how to set up a /program/ feed
for archive.  The "archive" program currently does NOT support this
method.  i.e. do not use Tp in "newsfeeds" for an archive feed.

Even if "archive" supported being used as a program feed, you would not
want to use it as such if you intended to use the ``-i'' flag as
archive does not do any file locking on it's index file.  The index
file might get corruped by multiple concurrently running instances of
archive, as may happen with a program feed.


------------------------------

Subject:  How do I restrict access on certain newsgroups (like alt.sex)

>If I were running a news server, and some of my users complained that they
>didn't want their kids being able to access some of the newsgroups, would it
>be possible to block access to specific newsgroups on a per-user basis?

>I'm not asking if it's easy, just _possible_.

If they are not using NNTP for reading, you can make a /etc/group entry
for a group called something special, like "horny" and give only users
in group horny access to read that directory:

    chown news /var/spool/news/alt/sex
    chgrp horny /var/spool/news/alt/sex
    chmod 750 /var/spool/news/alt/sex
    chmod 750 /var/spool/news/over.view/alt/sex    # your NOV data
    chmod 770 /var/spool/news/in.coming
    chmod 770 /var/spool/news/out.going

Now only people in the group "horny" can read that newsgroup.  Everyone
can subscribe to it, but only horny people can read it.  innd (which
runs as "news") will still be able to do its business.

If the users are using NNTP, then you need a newsreader that can tell
the server what the user's name is.  nnrpd will use that information
(see the nnrp.access man page) to restrict newsgroups.  If the
newsreader software doesn't support this then you can restrict this on
a per-host basis.  horny people would have to read netnews from a
particular machine or machines.

In 1.5 there will be a better protocol for doing this and it should
gain better acceptance than the current protocol.


------------------------------

Subject:  INN on one machine, UUCP modem on a different one

Say you have a machine named "newsy" and "modemhead".  "newsy" runs INN
but only "modemhead" has any modems.

A quick overview:  config.data has a variable called "RNEWSLOCALCONNECT".
If it is set to "DO", "rnews" will expect to be running on the same
machine as "innd".  On the other hand, if "RNEWSLOCALCONNECT" is set to
"DONT" then "rnews" will connect to the machine listed in "inn.conf".
Sending batches is a little more complicated.

Receiving batches on modemhead:  Make sure config.data has
"RNEWSLOCALCONNECT" set to "DONT", recompile, and copy /bin/rnews and
/usr/lib/news/inn.conf to modemhead.  The unbatching will be done on
modemhead, but the articles will be sent to newsy.  It will work like
magic.  When /bin/rnews runs, it will open an NNTP connection to newsy
and feed the batch (one article at a time) to newsy... newsy thinks
it's just getting a regular NNTP feed.  (which means modemhead has to
be listed in hosts.nntp).  If newsy and modemhead are different platforms
(i.e. Ultrix vs. SunOS) you can use the MakeRnews script (mentioned
in Install.ms) to generate just rnews for the modemhead machine.

Sending batches via modemhead:  The "sendbatch" program calls $(UUX).
Change ${UUX} to be something like "rsh modemhead uux" instead of "uux".
You'll have to do a little hacking on sendbatch.  For example, the part
that checks to see if the queue is full might have to be re-written.
Anyway... now the batches will be generated and send via modemhead's
UUCP system.

Pretty neat, eh?


Other advice:

I set UUX to 'rsh uucphost uux' (note no pipe [|]).
Also, we have no 'uuq' command, but even if we did, it would have
    returned bogus info as $SITE is not known to UUCP on newshost.
    Thus I created a stupid 'uuq' that does 'echo 0 0 0 0 0 0 0'
    to satisfy the awk script.  However, we have no way to monitor
    queue length (though its of little importance to us as we only have
    3 feeds and they are partial)
Finally, the /etc/passwd entry for 'news' on 'uucphost' MUST list /bin/sh;
    /bin/csh results in 'rnews: event not found' and escaping the '!'
    inside sendbatch had no effect.


------------------------------

Subject:  Setting up proxy-nntp to talk through a firewall

Try ftp.cs.cmu.edu:misc/dnntpd/dnntpd.tar.Z

or look at backends/rcompressed.c in the INN distirbuiton.

------------------------------

Subject:  How do I set up inpaths with INN?

inpaths should work just fine with INN as it ships.  However, you can
make it run faster by using the following shell script.  Edit it to
your tastes.  It replaces the long "(cd /var/spool/news ;
/usr/local/bin/gfind . -type f -print | /usr/lib/news/local/inpaths sdl
| /usr/ucb/mail admin,[e-mail] )" which people usually
use.

#!/bin/sh
. /usr/lib/news/innshellvars
cd ${SPOOL}
awk '(NF > 2){print $3}' < ${HISTORY} | tr . / | sort | \
inpaths `innconfval pathhost` | \
${MAILCMD} newsmaster,[e-mail]

If the inpaths people would include this information in the
README, I could delete it from this FAQ.


=====================================================================
                           INFO ABOUT 1.5
=====================================================================

INN 1.5 hasn't been released yet.  However, people constantly mis-type
"INN 1.5" when they mean "INN 1.4".  The bug is in the human posting
the message, not the software.

Release date for 1.5:  Unknown by even the author.

New features in 1.5:

1)  Fix memory leaks in makehistory, thereby speeding it up.

2)  Posting always allowed, even when server is throttled.

3)  Operating systems that require HAVE_UNIX_DOMAIN set to DONT won't
    be so, uh, handicaped.

4)  A global killfile controlled by a function you write in TCL.
    (Start learning TCL now if you want to stay totally hip.)

5)  More interesting ways to control access to nnrpd.

6)  More support for systems that don't have symbolic links.

7)  Free beer.

8)  Just kidding about #6.

None of these features prevent you from having a happy,
healthy and productive life with INN 1.4sec.

DO NOT ASK RICH ABOUT 1.5.  IT WILL BE RELEASED WHEN IT IS DONE, NOT
WHEN SUFFICIENT NUMBERS OF PEOPLE HAVE ASKED WHEN IT WILL BE FINISHED.
Post to news.software.nntp if you have questions about features.


=====================================================================
                             BUGS IN 1.4
=====================================================================

UNOFFICIAL patches for INN 1.4 are available via anonymous FTP at
ftp://ftp.pop.psu.edu/pub/src/news/inn/patches

The file ftp://ftp.pop.psu.edu/pub/src/news/inn/patches/README describes
each of the UNOFFICIAL patches.

The ones that are highly recommended are:

1.4-to-1.4sec     -- Fixes the major security hole in INN.
1.4sec-to-1.4sec2 -- Fixes the remaining known security hole in INN.
select-loop-bug.patch -- Under some circumstances innd can lose track
        of a file descriptor and end up sitting in a select()
        loop.  If your INN suddenly is using up tons of CPU
        time and not getting much done, install this UNOFFICIAL
        patch.  Some OSs are more susecptible to this bug.

THERE ARE MANY MORE at that site, many add some useful features.

There is a replacement for innwatch that is written in Perl.  Get it from
"ftp://ftp.univ-lyon1.fr/pub/unix/news/inn/contrib/innwatch-beta2.pl.gz".
This directory is mirrored on ftp://ftp.pop.psu.edu/pub/src/news/inn/contrib


=====================================================================
                             BUGS IN 1.3
=====================================================================


------------------------------

Subject:  7-bit encoded batches are not correctly processed. Why is this?

Chris Schmidt <[e-mail]> replies:

The decode program that comes with INN up to version 1.3 is broken.
Because of that the last article in a 7bit encoded batch will not
correctly be decoded (the last characters are screwed up).  This is
fixed in INN 1.4.


------------------------------

Subject:  NOV (overchan) doesn't work well.

Correct.  The NOV support in 1.3 didn't have all the bugs worked out.
Don't use NOV under INN 1.3.  Better yet, upgrade to 1.4sec and get all
the benefits!


=====================================================================
                             BUGS IN 1.2
                 (Hey, it's 1994!  Upgrade already!)
=====================================================================

------------------------------

Subject:  Why doesn't nntpget work?

The nntpget in INN 1.2 doesn't work.  Period.  Upgrade to the latest
version of INN.

--
 George Will, Rush Limbaugh, John Sununu, Pat Buchanan, James Kilpatrick, Mona
  Charen, G. Gordon Liddy, Robert Novak, Bay Buchanan, Pat Robertson, Joseph
   Sobran, Paul Harvey, Phyllis Schafly, Maureen Reagan, and John McLaughlin
          always bemoan the need for more conservative media voices.
Posted-By: post_faq 2.10
Archive-name: usenet/software/inn-faq/part4
Last Changed: $Id: FAQ-inn.4,v 1.6 1994/12/10 17:59:38 tal Exp $

This is a separate guide for installing INN addressed to
UNIX and System Administration novices.  It is written for
installation of INN 1.4 on a Sun SPARCstation 10/30 running
Solaris 1.1 (SunOS 4.1.3).  This guide is maintained by
Norman J. Pieniazek ([e-mail]).  Please
send updates and corrections to him.

This guide is composed of following parts:

  I. SYSTEM REQUIREMENTS
 II. INSTALLATION OF INN 1.4
III. UPGRADING FROM INN 1.3 TO INN 1.4
 IV. MAINTENANCE OF INN
  V. INSTALLATION OF XVNEWS, A SUN OPENWINDOWS
     NEWSREADER



I. SYSTEM REQUIREMENTS

  1. INN will not install nor run on Sun SPARCstation under
     plain Solaris 1.1 unless you install some software
     packages and utilities.  Also, your machines IP number
     has to be entered in a Domain Name Service database
     (DNS) to be resolvable.  Ask your Network Administrator
     about DNS or read the O'Reilly & Associates, Inc.
     book: "DNS and BIND by Paul Albitz & Cricket Liu,
     ISBN 1-56592-010-4.

     Further, test the resolver on your machine by
     pinging a hostname not entered in your /etc/hosts file.
     For example, type:
      ping ncbi.nlm.nih.gov
     The response should be:  "ncbi.nlm.nih.gov is alive".
     If you get: "unknown host", consult the O'Reilly book.

  2. Be sure to su to root before performing tasks
     outlined below.  Next, check if you have a directory
     /usr/local and about 90 Mb of space in the partition
     where this directory is located.  Create directories:
     /usr/local/bin, /usr/local/lib and /usr/local/man if
     you do not have them.  Add /usr/local/bin to your path
     and /usr/local/man to your MANPATH.

  3. INN uses gnu versions of grep, awk and sed.  Moreover,
     it is  recommended to compile INN with the gnu
     versions of make and the gnu gcc compiler instead of
     the Sun's unbundled cc compiler.  If you don't have
     the gnu software package, create a directory
     /usr/local/gnu, cd to this directory and ftp to
     aeneas.mit.edu (18.71.0.38). Go to
     directory /pub/gnu and get the following files
     (versions as of February 4, 1994):

      bison      bison-1.22.tar.gz
      gawk       gawk-2.15.4.tar.gz
      gcc        gcc-2.5.8.tar.gz
      grep       grep-2.0.tar.gz
      gzip       gzip-1.2.4.tar
      make       make-3.70.tar.gz
      patch      patch-2.1.tar.gz
      perl      perl-4.036.tar.gz
      sed        sed-2.03.tar.gz
      texinfo    texinfo-3.1.tar.gz

     Installation of these programs is quite complicated,
     but is really beneficial.  After you complete the
     installation, check if older versions of these programs
     are not present somewhere in your path.  Delete or
     rename these old versions.

   a. Start with gzip.  In /usr/local/gnu type:
      "tar xvf gzip-1.2.4.tar".  A directory gzip-1.2.4 will
      be created.  Change to this directory and type:
      "sh ./configure".  Next, edit the Makefile
      with the vi editor and change the line starting with
      "CC" to read: "CC = cc". Then, type: "make".
      Compilation should complete without errors.  Finally,
      type: "make install" to complete installation of gzip,
      gunzip, and other utilities in /usr/local/bin.

   b. Compile and install texinfo - info, makeinfo, the GNU
      hypertext system.  Makeinfo is needed for successful
      installation of many GNU programs and utilities.
      In /usr/local/gnu type: "gunzip texinfo-3.1.tar.gz".
      Next, type: "tar xvf texinfo-3.1.tar".  A directory
      texinfo-3.1 will be created.  Cd to this directory
      and type: "sh ./configure".  Next, edit the Makefile
      as described above for gzip.  Now, type: "make"
      and ignore any non-fatal errors.  Finally, type:
      "make install".

   c. Uncompress, compile and install gnu make.  Follow the
      steps described for texinfo.  Gnu make will install in
      /usr/local/bin.  To disable Sun's make, cd to /usr/bin
      and type: "mv make make.sun".

   d. Compile and install bison following the procedure
      described for texinfo.

   e. Uncompress gcc.  Cd to /usr/local/gnu/gcc-2.5.8 and
      type:
        sh ./configure --target=sparc-sun-sunos4.1
      Next type:
        make LANGUAGES=c
      This step will take about 17 minutes to complete.
      Ignore warnings reported for insn-emit.c.  Next, type:
        make stage1
      Ignore reported non-fatal errors.  Next, type:
        make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O"\
        LANGUAGES=c
      This step will take about 19 minutes to complete.
      Next, type:
        make stage2
      Ignore reported non-fatal errors.  Next, type:
        make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O"\
        LANGUAGES=c
      In this step, which lasts about 13 minutes, you will
      make the final stage 3 compiler.  Now type: "make
      compare". No errors should be reported here.  Finally,
      type:
        make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g\
        -O" LANGUAGES=c
      to install the gcc compiler.  It is advisable to
      recompile patch, gzip, texinfo, make and bison with
      gcc.  It will be a good test for proper gcc
      functionality.

   f. Uncompress gawk. Cd to directory gawk-2.15.4 and type:
        ./configure sunos41
      Next type: "make".  When gawk will compile, type:
        make install
      Finally, disable Sun's awk by typing:
        mv /usr/bin/awk /usr/bin/awk_sun
      and create a link to gawk for awk by typing:
        ln -s /usr/local/bin/gawk /usr/bin/awk

   g. Uncompress grep.  Cd to directory grep-2.0 and type:
        ./configure
      Next type: "make" and "make install".  Grep will
      also be installed in /usr/local/bin as fgrep
      and egrep.  Finally, as some programs expect to find
      grep, egrep and fgrep in /usr/bin, disable Sun's grep
      and create appropriate links, just like described
      for awk.  INN expects to find a program "egnugrep" in
      /usr/local/bin.  Create it by typing:
         cp /usr/local/bin/egrep /usr/local/bin/egnugrep

   h. Uncompress sed and patch.  Compile and install these
      utilities following the instructions for grep.


   i. INN comes with some scripts written in the perl
      language.  Uncompress perl, cd to directory perl-4.036
      and type:
       sh ./Configure -d
      and hit Return for default answers to all questions.
      Next, type: "make depend", then "make".  Now type:
       make test
      to check, if perl works without errors.  Finally,
      type:
       make install
      to complete installation of perl.



II. INSTALLATION OF INN 1.4


  1. As root, create directories: /usr/local/inn1.4 (this
     will be your $inn directory) and /usr/local/news.

  2. Cd to $inn. Get: inn1.4sec.tar.Z from ftp.uu.net
     (192.48.96.9).  This file is in the directory:
     /networking/news/nntp/inn.   As for all files, please
     remember to set the file type in ftp to binary.

  3. From the same source and directory get the Frequently
     Asked Questions (FAQ) files:
       faq-inn-1.Z
       faq-inn-2.Z
       faq-inn-3.Z
       faq-inn-4.Z (this file)
       faq-nov.Z

  4. To uncompress the FAQ files type: "uncompress faq-*.
     Print the FAQs and read them before proceeding further.

  6. In $inn type: "zcat inn1.4sec.tar.Z | tar xvf -".  This
     will install inn files for compilation.

  7. Change directory to $inn/config, and type:
       cp config.dist config.data
       chmod 644 config.data
     Now use the vi editor to edit config.data.  You should
     select gcc as the compiler by changing the line that
     starts with "CC" to read "CC   gcc".  Many lines in
     config.data define the location of various files
     and directories.  It's OK to leave defaults, but
     check if you have ample space in the partition
     where the articles will be stored (/var/spool).  More
     information on where INN expects to find certain files
     is in: $inn/samples/innshellvars.  If necessary, edit
     the config.data and innshellvars to reflect your
     configuration.  Please make sure that specified
     directories and utilities exist on your system.

  8. Change directory to $inn.  Type: "make world".  Now
     type:
       cat */lint
     Here, you will get a list of compiler warnings and
     errors.  In addition, "make" created in this step
     a file:  "$inn/Install.ms".  Print it by typing:
       nroff -ms Install.ms | lpr
     Install.ms is a manual for installation of INN written
     by Rich Salz, the author of INN.  There is a lot of
     important and interesting information in his manual.

  9. If you got no fatal errors from make, go to the
     $inn/site directory
     and type: "make all".

 10. There are some scripts and control files listed in
     inn-faqs and Install.ms that may be modified at this
     point.  For most installations, the default settings
     are OK.

 11. Now cd to $inn and type: "make install" to complete
     basic installation of INN.

 12. To finish installation of INN, run the BUILD script
     in the $inn directory by typing "sh BUILD".  This
     script will ask a series of configuration questions
     that are easy to answer.  Please note that if your have
     "history.*" files in your /usr/local/news directory
     from a previous or failed installation of INN, the
     BUILD script will not complete.  Rename them to
     "old.history.*" and re-run the BUILD script.

 13. You need a site that will feed news to you.
     This will depend on your geographic location and
     organization.  Ask a System Administrator of a site
     close to you for hints.

 14. Ftp to your newsfeeding site and get the "active" file
     from there.  Place this file in your /usr/local/news
     directory and edit it to your taste.  Remember to
     include the "control" and "junk" newsgroups.  Also, you
     have to edit the following files in /usr/local/news:
     newsfeeds, hosts.nntp and nnrp.access.

 15. To check for syntax errors in INN control files,
     file ownership, permissions and other things type:
       /usr/bin/perl /usr/local/news/bin/inncheck
     and correct any errors reported by inncheck.

 16. Look at the file "rc.news" in /usr/local/etc.
     It's advisable to enable the innwatch utility.
     Innwatch will throttle the newsserver when your disk
     will get full and prevent crashes.  Change the line
     starting with "DOINNWATCH" to read "DOINNWATCH=true".
     Now type: "sh /usr/local/etc/rc.news"
     and look in /var/log/syslog for errors.  Also, type:
       ps -aux| grep news
     and check, if the innd process owner is news.

 17. In /etc/aliases create an entry: "usenet: <you, or
     root>".  Next type: "/usr/ucb/newaliases" to inform the
     sendmail program that the aliases file has changed.
     If you are running YP (NIS) on your network, you may
     optionally add the "usenet" alias to your YP aliases
     file.  If the machine you are installing INN on is the
     YP master and the file "/etc/aliases" is the source of
     the YP aliases map, you should type: "cd /var/yp"
     followed by "make".  Reboot and restart innd (see #16).


 18. To get daily reports on the newsserver activity from
     the "news.daily" script and to enable the "expire"
     utility type: "/bin/crontab -e news" and insert the
     following line:
       40 23 * * * /usr/local/news/bin/news.daily delayrm
     or, if you are using overchan (in newsfeeds):
       40 23 * * * /usr/local/news/bin/news.daily delayrm\
       expireover

 19. To set-up complete logging of the server activities
     and have them ready for a report by the "news.daily"
     script, you have to edit your /etc/syslog.conf file.
     Insert at the end of this file the content of
     the syslog.conf file written by Rich Salz.  This file
     is in: $inn/syslog.  Please check, if you have the
     directories and files mentioned in Rich's syslog.conf.

 20. Run tests from your machine to the server (to your
     machine at telnet port 119).  See inn-faqs for details.

 21. After completing these test, be sure to delete the
     entry for your machine from the hosts.nntp file.  If
     you will not do it, your machine will be treated as a
     "feeder" and not as a "reader".

 22. Set posting.

      a. Edit the /usr/local/news/newsfeeds file and add:
           <alias for your feed>/<full address of feed\
           :*\ (for all local postings)
           :Tf,Wnm: (standard entry)

      b. Edit /usr/local/news/nntpsend.ctl file and add:
           <alias for your feed>:<full address of feed>::\
           -T1800 -t300

      c. Type: "/bin/crontab -e news" and insert a line:
           0,10,20,30,40,50 * * * *\
            /usr/local/news/bin/nntpsend

      d. Run inncheck (see #15).

      e. Post to misc.test and include "reply" in the
         Subject line, automatic responses will be mailed to
         usenet (see #17) within a few minutes.

 23. To start innd automatically at bootup, include at the
     end of your rc.local the following lines:

      #
      # Start INN news service - Internet News Daemon (innd)
      #
      if [ -f /usr/local/etc/rc.news ]; then
         /usr/local/etc/rc.news; echo "Starting INN news
                 service"
      fi

 24. Watch the news.daily reports in your mail for any
     additional errors.  To run the news.daily script
     at any time manually, FIRST SU FROM ROOT TO "news"
     and type: "/usr/local/news/news.daily".  A mail to
     "usenet" should arrive within a couple of minutes
     and may report important configuration problems.


III. UPGRADING FROM INN 1.3 TO INN 1.4

  1. Stop the server.  Type:
       ctlinnd shutdown "upgrade"

  2. Create a directory /usr/local/inn1.4, this will be
     your $inn directory.  cd to $inn.  Next, ftp to
     ftp.uu.net, cd to directory: /networking/news/nntp/inn
     and get the following files:

        inn1.4sec.tar.Z
        faq-inn-1.Z
        faq-inn-2.Z
        faq-inn-3.Z
        faq-inn-4.Z (this file)
        faq-nov.Z
     Uncompress and print the FAQs.  Next, type:
        zcat inn1.4sec.tar.Z | tar xvf -

     Print the README file.  To print the Install file,
     type: "make Install.ms" followed by:
        nroff -ms Install.ms | lpr

  3. Now, cd to $inn/config and type the following commands:
        make subst
        cp config.dist config.data
        ./subst -f {OLDFILE} config.data
     where {OLDFILE} is the location of config.data in your
     INN 1.3 directory.  Be sure to check, if in your old
     config.data the "CC" line reads "CC  gcc".
     Ignore warnings about new lines.  Next, type:
        make sedtest
     No errors should be reported here.  Now, cd to $inn
     and type this series of commands:
        make quiet
        cd ../lib
        make libinn.a lint
        cd ../frontends
        make all
        cd ../innd
        make all
        cd ../nnrpd
        make all
        cd ../backends
        make all
        cd ../expire
        make all
        cd ../site
        make all
        cd ..
        make update

  4. Restart innd.


IV. MAINTENANCE OF INN

 1. Adding new groups - see also Part IV, Section 3.b,:

     a. Type: "ctlinnd pause 'edit active'"

     b. Edit the active file.  The format is:
          groupname himark lomark flag.
        Set himark to 0000000000 and lomark to 0000000001.

    c. Run inncheck (see #11) to check the new active file
       for errors.

    d. Type: "ctlinnd reload active 'new active'".

    e. Type: "ctlinnd go 'edit active'".


 2. New groups are sometimes added automatically through
    a control message.  A mail message to usenet will alert
    to such an automatic change to the active file.  If you
    do not want to subscribe to a particular news group,
    change directory to /usr/local/news and type:
      ctlinnd rmgroup <group name>

 3. Sometimes, a mail message will arrive for usenet with
    a checkgroups file.  Remove header, save the body of
    the message in:
      /usr/local/news/bin/control/news_control/news_control_
                    todaysdate
    cd to that directory and type:
      ../docheckgroups <news_control_todaysdate
             >todaysdate_pre
    Read the output file (todaysdate_pre) and carry out all
    the instructions that you think pertain to your
    situation.  Read the man pages for "active" and "ctlinnd"
    for more info.  To implement the changes, you will have to
    change to the directory: /usr/local/news and:

     a. remove a discontinued group:
          type: "ctlinnd rmgroup <group name>"

     b. add a group:
        type: "ctlinnd newgroup <group name> flag <creator
                                           name>"

     c. mark a group correctly:
        type: "ctlinnd changegroup <group name> flag"

    Run inncheck and repeat the docheckgroups command from
    the /usr/local/bin/control/news_control directory
    by typing:
      ../docheckgroups <news_control_todaysdate
                                >todaysdate_after
    Correct any reported problems.  Also, you may have to
    edit the /usr/local/news/newsgroups file to reflect
    any changes you introduced.

 4. Subscribe to and read the following newsgroups:
      news.software.nntp
      news.software.readers


 5. IMPORTANT!!! Never run fsck on the drive where the
    /spool/news files are located while running INN.  Innd
    has a lot of active disk I/O going on and fsck will show
    a lot of errors.
    Use ctlinnd to throttle,  pause, or shutdown innd first
    - see the manual page for ctlinnd.


  V. INSTALLATION OF XVNEWS, A SUN OPENWINDOWS
     NEWSREADER

   1. Create a directory /usr/local/xvnews2.1 and cd to this
      directory.

   2. Ftp to dutiws.twi.tudelft.nl and get the file
      xvnews.tar.gz from directory /pub/news.

   3. Ungzip and untar xvnews.

   4. Use your vi editor and edit the file xvnews.h
      You will need to enter your settings for:
        DOMAIN         (on my machine: "pdb.cdc.gov")
        ORGANIZATION   (on my machine: "Centers for Disease
                          Control Atlanta, GA, USA")
        NNTPSERVER     (on my machine:
                               "giardia.pdb.cdc.gov")
      These defaults can be overridden by environment
      variables (see the xvnews man page).

   5. Compile xvnews by typing: "make".  I get some errors
      on my system, but the program runs OK.  Copy xvnews
      to /usr/local/bin and xvnews.man to directory:
      /usr/local/man/man1 as xvnews.1

--
 George Will, Rush Limbaugh, John Sununu, Pat Buchanan, James Kilpatrick, Mona
  Charen, G. Gordon Liddy, Robert Novak, Bay Buchanan, Pat Robertson, Joseph
   Sobran, Paul Harvey, Phyllis Schafly, Maureen Reagan, and John McLaughlin
          always bemoan the need for more conservative media voices.